Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.


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.


I don‘t think you‘re allowed to send once per second on LoRa if you play by the rules due to duty cycle restrictions in the license-free ISM bands.

On 868Mhz you get 36 seconds per hour or even 3.6 seconds per hour.

Depending on your power usage sending may also be very slow.


Depends on the region. That duty cycle limitation sounds like EU. In USA, there are fewer restrictions on 915MHz, but heavy limits on 434 MHz under part 15. (Subsec 15.235 does not permit pre-determined intervals and 1/sec would definitely not fly!)

Then again, the primary user of 434MHz is actually amateur radio, on which you can operate beacon transmissions if you care to!!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: