Record but not transmit in Online Mode


at the moment with the rapidM2M Modules, when the device is in Online mode, any data that is recorded is trasnmitted to the cloud immediately.

Is there a way, to record a certain amount of data, before transmitting the data??
A way to only record and keep recording for sometime in Online mode, before triggering a transfer??

Yes I can do this in the Program RAM. Collect the data before recording. But the size here is limited and there is no compression when I add more data.

So I want to keep recording, but wait to transmit. In Online mode.

Thanks in Advance.

Cheers - Kaushik


staying online, but not sending newly recorded data is not foreseen yet. your demand looks a bit exotic to me, and i would like learn more about it. can you please explain your use case?


Hallo Andreas,

thank you for your reply.

It is simply to make use of the data compression techniques used in the other transmission modes. In interval mode, I can collect data for many hours or days before connecting and transmitting. And the data is compressed here. Not by much, but still there is a reduction.

Use case from customer:

  1. 24 x 7 Availability required. Always online.
  2. Data is always recorded and stored for a time period of 2 hours. Total data: 800 bytes / s
  3. Alarms to be recorded on several channels.
  4. When there is an alarm, the recorded data is then transmitted. Otherwise, data is overwritten.

Do you have an idea how this can be realised, without using the RAM??

Thanks in Advance.


Hi Kaushik,

I understand your idea, but ONLINE means, that there is always some data exchange (at the lowest possible rate) between device and backend in the background.

This is necessary, to keep lines open and to “continuously” check that the connection is still up and running (because all the routers and firewalls in the global network infrastructure blur the ability of TCP/IP to detect broken sockets and may cut the line w/o reliable indication).

So in fact, when you are ONLINE, compression is always affected by this background communication.

If you want to reduce data volume to a minimum, but still want to contact your device at a finger-tip, i recommend to use the WAKEUP operation. this means the device drops the data line, but listens for some wake-up SMS sent by the backend. you can fire this SMS either over the backend’s portal, or the backend’s API.

Of course, this wakeup action takes a few seconds and is not perfectly “just in time”.

Therefore advanced apps toggle dynamically between ONLINE and WAKEUP.

  • They use WAKEUP by default, but turn the device to ONLINE as soon as the user is looking at it (via his UI). Since the device is then mostly already ONLINE before the user fires his action, he suffers less from wakeup delays.
  • The device falls back to WAKEUP mode as soon the user leaves the device/site on his UI
1 Like

no - using time-shift buffers in the RAM is your only option

in fact it appears to me the best choice, since permanently blowing 800byte/s over the line is already some high load for IoT applications.

if the device’s core memory is too tight, you may eventually use I2C RAM or FIFO buffers (or even a tiny co-processor for capture & time-shift) ?

Hallo Andreas,

wow!! Thank you for your answer! Many of your ideas are interesting and I will certainly look in to this!

Especially the idea of keeping the device in WAKEUP mode and turning it to ONLINE mode via the UI looks promising. I will certainly look in to this.

The Co-Processor is already available. At the moment it is busy with other interface tasks, but maybe it can take up some more load! :slight_smile:


1 Like