0

I have a system like the image shows. Now instead of it being connected with an Ethernet cable, it is going to be wireless.

The SBC's represent Raspberry Pi's. SBC0 reads the data all the time and is supposed to send it to the other SBC1. My options are to implement a time/event or mix both functions in the SBC0. If it is a time trigger, then based on the interval chosen, the data from the sensor will be sent constantly even if the temp is 0c. With event trigger, it will only send the data when it meets the right condition. Lastly, a mix uses both, so data will only be sent if the condition is met for the duration of that condition, and the data would be sent based on the time interval that is chosen.

This is all done in packet tracer and using UDP.

I have concluded that a time trigger would cost a lot on the network traffic and instead use a triggered system, but then the issue was that when the desired condition for the triggered system was met, the system would spam constantly. I figured out that maybe it is best to use a mix of both where the data won't send to the primary system if it is not above 24 C, and if that is maintained, it will send the sensor's data every 2s.

I would love it if anyone could give me feedback on this, is my reasoning completely wrong or have I messed something up, and if it should be triggered or timed instead of a mix of both. For a system like this, what is the best interval 2s or more?

image of system

Improve this question
9
  • 2
    Why not used acknowledgments? Send an alarm packet when you exceed the threshold, wait for an ACK, repeat if not ACK, stop once you’ve received an ACK. Adjust timers as needed. Don’t forget to randomise the repeat interval. And add hysteresis.
    – jcaron
    Apr 20, 2021 at 19:54
  • 1
    It's hard to give you more input if we don't understand the constraints. Why is an acknowledgement not okay?
    – Helmar ♦
    Apr 21, 2021 at 7:20
  • @Helmar, ok it turns out it is fine if I use an acknowledgement of some sort. Maybe the question was not clear enough, both SBC represent a raspberry-pi, now the first SBC0 reads the data from the temp sensor all the time. That data is then sent to the other SBC1. I am conflicted with how that data should be sent, in the question above I determined that a timed trigger was expensive on the network and pointless because the data would send temp data that we are not interested in, that why I think it it either event or an mix of both. The alarm/fan are just examples in Packet tracer
    – zellez
    Apr 21, 2021 at 10:55
  • If you need to have a history, then sending data at regular intervals can be useful, though probably not at such a high frequency. It's also useful to have regular updates to be sure the sender is still "alive", though, again, probably not at such high frequency. Systems often use a combination of both: send an update (with ACKs and retries) when a condition changes (so that you have a quick reaction), and send updates on a regular basis (but probably a lot less often) just as a "backup" and to be sure everything is fine. But it all really depends on your constraints. Start by defining those.
    – jcaron
    Apr 21, 2021 at 11:01
  • I'm with @jcaron on this. Here's a slightly different take: The reason you're having to broadcast at a higher rate is probably because you dont have the concept of responding to a request and without the high broadcast rate, the receiving system may have to go a long time without data when turned on. So, have a "periodic broadcast" rate of say, 30 sec. But also send immediately send on change and on request. If you have significant packet loss, add acks.
    – kalyanswaroop
    Apr 21, 2021 at 14:47

0

Reset to default

Your Answer

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

Browse other questions tagged or ask your own question.