I am designing a remote station which will occasionally (say every 30 minutes) report sensor data to a base station. In between sending this data, the remote station will fall asleep in order to save power (and thus will not be listening for any messages which the base station might receive).
I would like to be able to send certain settings data to the remote station (for example, changing the measurement interval period). I am trying to think of the best way to do this whilst keeping power usage of the remote station low. I see two possible options:
Have the remote station wake up at a certain time each day and listen for messages for a specified period.
Program the remote station so that, after sending the sensor data, it waits for a short period (say 5 seconds) to see if any messages are incoming. The base station would be programmed to automatically send the settings (if the user wanted to) upon receiving the sensor data.
I would be grateful for any thoughts on which option might be best (or the factors which may be relevant to making that decision). If there are any other options which I might want to consider, please feel free to mention these.
No 1 would need you to keep the transmit and receive synced in time, not at all easy.
If No2 is acceptable, there will be little in terms of wasted power. A wait of 500mS or so ought to be enought time to turn around between transmit and receive a reply. With this method the transmitter, on receiveing a response from the remote receiver, has in effect had an acknowledge, so it knows its message has been received and could maybe retry the send again.
For most applications LoRa will provide the lowest power solution, for a particular distance it can use far less transmit power that other radio types.
Its also easy to get carried away with radio stuff and assume that a received packet has valid data, but that packet could be from another source. If you accept it as valid it could mess up you readings. So you do need some method of checking the packet received really does contain data from your transmitter.
srnet:
No 1 would need you to keep the transmit and receive synced in time, not at all easy.
I should have mentioned that the base station has a rtc and it will intialise the remote station by sending the epoch time. Both the base and the remote station should therefore know the current time.
srnet:
If No2 is acceptable, there will be little in terms of wasted power. A wait of 500mS or so ought to be enought time to turn around between transmit and receive a reply. With this method the transmitter, on receiveing a response from the remote receiver, has in effect had an acknowledge, so it knows its message has been received and could maybe retry the send again.
For most applications LoRa will provide the lowest power solution, for a particular distance it can use far less transmit power that other radio types.
Thanks, I'm using LoRa.
srnet:
Its also easy to get carried away with radio stuff and assume that a received packet has valid data, but that packet could be from another source. If you accept it as valid it could mess up you readings. So you do need some method of checking the packet received really does contain data from your transmitter.
Thanks, I have a system to check that the messages are valid.
Is knowing the time important to the remote station? The remote station could maintain a software RTC using the base station time broadcast. However, depending on the power reduction setting you select, the internal timers may be suspended as well, effectively pausing your software RTC.
If it doesn't matter when your 30 minute reporting happens, say 10 minutes past the hour and 40 minutes past the hour, or 20 minutes past the hour and 50 minutes past the hour, then your remote station may not need to know what time it is. Just that 30 minutes (or so) have passed and it's time to send a message to the base station.
EDIT: You can achieve around 30 minutes "sleep" time with multiple 8 second watchdog timeouts. Just remember that the watchdog isn't particularly accurate. With RFM69HCW nodes that I have, a 1 hour "sleep" period tends to be more like 1hr 4min or so on average.
If you are rolling your own protocol as it were, then your ACK packet back to the remote station could include a payload with new settings in it.
markd833:
Is knowing the time important to the remote station? The remote station could maintain a software RTC using the base station time broadcast. However, depending on the power reduction setting you select, the internal timers may be suspended as well, effectively pausing your software RTC.
If it doesn't matter when your 30 minute reporting happens, say 10 minutes past the hour and 40 minutes past the hour, or 20 minutes past the hour and 50 minutes past the hour, then your remote station may not need to know what time it is. Just that 30 minutes (or so) have passed and it's time to send a message to the base station.
EDIT: You can achieve around 30 minutes "sleep" time with multiple 8 second watchdog timeouts. Just remember that the watchdog isn't particularly accurate. With RFM69HCW nodes that I have, a 1 hour "sleep" period tends to be more like 1hr 4min or so on average.
If you are rolling your own protocol as it were, then your ACK packet back to the remote station could include a payload with new settings in it.
Thanks, I'm using a SAMD21 microcontroller so the internal timers should be maintained during sleep (I am in fact using the internal rtc to schedule wake up alarms to take measurements).
I just would not bother with the RTC and the application is ideal for a bare bones Arduino sleeping in steps of 8 seconds. With most all sensors its of little consequence if the 30 minutes is 25 or 35.
For an idea of how simple this sort of application look at this example below, this sends the sensor reading every 15 minutes, its been running now for 13 months on a tiny 155mAhr battery which is still far from flat. Expected battery life on AAs is 45years.
With the retained flag set to true on publication, when the client connects to the MQTT Broker the last/newest/latest publication will be one of the first things the connecting device will receive.
Idahowalker:
Send and receive data from an MQTT Broker.
With the retained flag set to true on publication, when the client connects to the MQTT Broker the last/newest/latest publication will be one of the first things the connecting device will receive.
Thanks, I hadn't come across MQTT.
I found this MQTT library but it doesn't look like it is LoRa compatible (it seems to expect a wifi client object). Are there any MQTT libraries which work well with LoRa?
There is nothing magic about the packets of data that a LoRa radio provides.
An application, such as MQTT that expects a sequence of bytes of data does not care and cannot know if that data comes from a LoRa radio or spark gap transmitter radio.