4 ms·

LoRa is actually pretty thirsty on receive. You’d need some scheme for synchronization if you want to reduce power consumption.

kingkawn 1y ago
Receipt for LoRa is low power, its transmission that kills the battery
- arghwhat 1y ago
  For any radio system, receiving continuously also kills battery, just not as fast as transmitting does. Low-power requires you to turn the receiver off for extended periods of time, but what you can do there is limited by how interactive the device needs to be, and how much the power the transmitter is willing to waste on retries/longer preambles. For proper low-power (e.g., devices with ≥ 1 year battery life on small batteries), you're likely to need sleep periods of minutes to hours, or only waking up on physical interaction.
- tonyarkles 1y ago
  Sort of. Keeping the receiver on and listening 24/7 is going to still use significantly more current than not having the receiver on and putting the microcontroller into a deep sleep mode. The approach in my sibling comment explains how IoT LoRaWAN devices are able to use ~0 current the vast majority of the time and run off, say, a CR2032 battery.
  - kingkawn 1y ago
    Ok great point if the device is on it will technically use more power than off, true
- numpad0 1y ago
  Receiving is just transmitting nothing to see how it's getting disturbed
  - subscribed 1y ago
    Wow, that's actually very poetic way to put it. Thank you.
tonyarkles 1y ago
To elaborate on this a little bit, the conventional use isn't peer-to-peer but rather sleepy IoT nodes that periodically wake up to send to a listening base station. The IoT node transmits and then waits a specified amount of time listening for a response back from the base station. The tradeoff is: - The end nodes can spend the vast majority of the time in deep sleep without the radios turned on. - The base station has access to a bigger power source (usually line voltage) and doesn't care about turning its receiver off. - You can't, however, send data to the end nodes at arbitrary points in time. You have to wait for them to send to you and you have to reply back to them before they go back to sleep. In a peer-to-peer system like the one in the article you don't get to make this tradeoff.
- IshKebab 1y ago
  There's no reason you couldn't do this in a peer-to-peer system too, especially if you only have a few nodes. Imagine for 2 nodes: 1. Each node transmits a beacon once per second. 2. While they aren't connected, each node listens for sub subset of time (say 10%). 3. Eventually one node will hear the beacon from the other. They can use this to synchronize clocks (the better your clocks the better this works). 4. Thereafter they just wake up periodically at the same time and one transmits a beacon to the other to synchronize (alternating whose turn it is). It's the same idea as sleepy edge devices used in IoT, but just both ways. Quite a lot more complicated of course, but you can totally do it.
  - tonyarkles 1y ago
    Yeah I've actually built a system like this before. The nodes didn't have power supplies with strong storage capacity but did have an infinite source of limited energy harvesting (they could extract a tiny amount of power from the environment they were monitoring). With the walkie-textie type system you're making a different tradeoff here though that would have to be measured and assessed. Now you've got a couple of knobs to twiddle with: - What's the max acceptable latency between sending a message and receiving it? That determines your beacon interval and becomes the factor that determines your battery life (effectively your Rx duty cycle + Tx beacon energy). - Does transmitting the beacon at your beacon interval and only having the receiver run in a limited window around that beacon result in a larger or smaller net power consumption? That's going to depend significantly on your transmit power vs. receiver power.

kingkawn 1y ago

Receipt for LoRa is low power, its transmission that kills the battery

arghwhat 1y ago
For any radio system, receiving continuously also kills battery, just not as fast as transmitting does. Low-power requires you to turn the receiver off for extended periods of time, but what you can do there is limited by how interactive the device needs to be, and how much the power the transmitter is willing to waste on retries/longer preambles. For proper low-power (e.g., devices with ≥ 1 year battery life on small batteries), you're likely to need sleep periods of minutes to hours, or only waking up on physical interaction.
tonyarkles 1y ago
Sort of. Keeping the receiver on and listening 24/7 is going to still use significantly more current than not having the receiver on and putting the microcontroller into a deep sleep mode. The approach in my sibling comment explains how IoT LoRaWAN devices are able to use ~0 current the vast majority of the time and run off, say, a CR2032 battery.
- kingkawn 1y ago
  Ok great point if the device is on it will technically use more power than off, true
numpad0 1y ago
Receiving is just transmitting nothing to see how it's getting disturbed
- subscribed 1y ago
  Wow, that's actually very poetic way to put it. Thank you.

tonyarkles 1y ago

To elaborate on this a little bit, the conventional use isn't peer-to-peer but rather sleepy IoT nodes that periodically wake up to send to a listening base station. The IoT node transmits and then waits a specified amount of time listening for a response back from the base station. The tradeoff is: - The end nodes can spend the vast majority of the time in deep sleep without the radios turned on. - The base station has access to a bigger power source (usually line voltage) and doesn't care about turning its receiver off. - You can't, however, send data to the end nodes at arbitrary points in time. You have to wait for them to send to you and you have to reply back to them before they go back to sleep. In a peer-to-peer system like the one in the article you don't get to make this tradeoff.

IshKebab 1y ago
There's no reason you couldn't do this in a peer-to-peer system too, especially if you only have a few nodes. Imagine for 2 nodes: 1. Each node transmits a beacon once per second. 2. While they aren't connected, each node listens for sub subset of time (say 10%). 3. Eventually one node will hear the beacon from the other. They can use this to synchronize clocks (the better your clocks the better this works). 4. Thereafter they just wake up periodically at the same time and one transmits a beacon to the other to synchronize (alternating whose turn it is). It's the same idea as sleepy edge devices used in IoT, but just both ways. Quite a lot more complicated of course, but you can totally do it.
- tonyarkles 1y ago
  Yeah I've actually built a system like this before. The nodes didn't have power supplies with strong storage capacity but did have an infinite source of limited energy harvesting (they could extract a tiny amount of power from the environment they were monitoring). With the walkie-textie type system you're making a different tradeoff here though that would have to be measured and assessed. Now you've got a couple of knobs to twiddle with: - What's the max acceptable latency between sending a message and receiving it? That determines your beacon interval and becomes the factor that determines your battery life (effectively your Rx duty cycle + Tx beacon energy). - Does transmitting the beacon at your beacon interval and only having the receiver run in a limited window around that beacon result in a larger or smaller net power consumption? That's going to depend significantly on your transmit power vs. receiver power.