I am configuring a Sonar Distance sensor to send data to a cloud. But the problem for me now is: I do not know when to send the data to this cloud.

As far as I know, I could send the data continuously every second. But in my case, the sensor does not always "sense" the signal. So sending data like the above method seems to be wasteful on network bandwidth.

I want to ask: Normally, with this kind of sensor; How do people often configure to send the data to a cloud?

  • 1
    This really depends on what you are doing with the data.
    – hardillb
    Commented Sep 29, 2018 at 20:41
  • I just want to make some analysis for my SmartHome project, and it is not used in a real-time manner. Commented Sep 30, 2018 at 8:23
  • Bottom line is - you send it as often as you want to see it, or as often as it could make a difference. And, if you have nothing to send, it's best to send nothing, although I would put an incrementing counter into every message, so that the server can detect when one is lost (and, possibly, ask for retransmission).
    – Mawg
    Commented Nov 14, 2018 at 7:38

2 Answers 2


Sending packets at a high rate 'feels' wrong, and does increase the chances of seeing some odd effects when the network latency spikes occasionally. In this instance, the fact that you're in a development cycle means that any period much above 10-30 sec will start to become painful to debug or adjust.

Batching up the readings is one option, or you can decimate (sample rate reduce) your readings before uploading them (depending on the application). You can also apply a rate-adaptive approach if there are some events that you want to be able to post-process more precisely.

At the highest level of 'not much change', you still probably want to see that the endpoint is alive, so even if you only used daily averaged/processed data, making an upload every hour might make some sense. If you want to measure occupancy, maybe anything over a 10% change would justify an instant update.

If you do anything other than a simple periodic update, consider what the worst case fault condition might look like. Even though a broken sensor won't burn through your monthly broadband allowance, it could cause some effects on your LAN which are inconvenient. It's always useful to think about the extra steps which you would take if this project made it to volume deployment, or if it becomes an exploit target.


I think the best way is to have a different interval for sending data over the air, and a different (preferably settable) time interval for logging the data into your data repository. How this helps?

Lets say you send data every second but log the data only ever 10 seconds

  1. You wont miss any alarms because you could analyse the data sent every 1 second and record and raise alert messages, but you need not store the data every second. Other wise you might miss an alarm in between if you only analyse the data for alarms every 10 seconds. What if the alarm occurred on the 4th second and then got reset on the 9th second?

  2. You will only occupy one tenth of the disk space which you will other wise occupy if you record data every 1 second.

This is a good practice for any type of remote telemetry application. Depending on your application and requirements you could tweak these time intervals to suit your needs.

  • thank you very much for your answer. But I am afraid that sending data every second could be quite wasteful on bandwidth, as I have mentioned in my question. It is so good for me to know the processing solution afterward :) Commented Oct 2, 2018 at 15:31
  • Most welcome and I hope my answer helped. The timing interval in my answer was just an example, like i mentioned in the end tweak the timing as per your needs. The logic is what is important and I hope you got it :)
    – Subbu
    Commented Oct 11, 2018 at 16:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.