LoPy broadcasting network

[derchris]

Dear all,

I'm pretty new in LoRa and currently rather working with Bluetooth LE.

I wonder if it is possible to build a "broadcasting network" with LoRa. What I mean by "broadcasting" is a setup where we have eg 20 relays switching lights on and off. These 20 nodes would be (as far as I understood) Class-C devices, which would only be in RX the whole time.
It is assumed that we don't need a feedback if the lights were actually turned on or off.

Alright, the other side would be a TX-only "broadcasting" device connected to the internet. As soon as a webhook "tells" the broadcaster that a specific light should toggle state, it would send a rather short payload consisting of the ID (say, uint8) of the device and a command ID (another uint8) in a UDP-manner (so all RX-nodes would receive this, which is okay).

To keep power consumption of the RX-nodes low, I guess they shouldn't be RXing really all the time. Would it make sense to have them receiving for, say, 10ms every 2000ms? Assumed the broadcaster would repeatedly send for at least 2000ms (via FSK to avoid fair use limitations).

Phew, thanks for reading - does it make sense at all?

[seb]

@derchris said in LoPy broadcasting network:

thank you @seb @bmarkus
Alright, I misunderstood the device classes, so I guess Class-A is fine.
Current (remember, newbie, but I have to start somewhere) is a LoPy as RX-only client and using a Laird Sentrinus Gateway for Multicast. TTN shows a blog post about OTA DFU here https://www.thethingsnetwork.org/article/firmware-updates-over-low-power-wide-area-networks/ and I think this is something I can take some ideas from

Thats a very interesting read, this relies on the same trick @bmarkus suggested where all devices use the same IDs and keys to be able to receive the same messages.

[derchris]

thank you @seb @bmarkus
Alright, I misunderstood the device classes, so I guess Class-A is fine.
Current (remember, newbie, but I have to start somewhere) is a LoPy as RX-only client and using a Laird Sentrinus Gateway for Multicast. TTN shows a blog post about OTA DFU here https://www.thethingsnetwork.org/article/firmware-updates-over-low-power-wide-area-networks/ and I think this is something I can take some ideas from

[bmarkus]

@seb said in LoPy broadcasting network:

I am afraid multicast this is not currently supported by our LoRaWAN stack. Its a planned feature but I am afraid I cannot provide any specific timeframe on when it would be added.

You could also use the raw LoRa mode of our devices.

What I described has nothing to do with LoRaWAN.

[seb]

I am afraid multicast this is not currently supported by our LoRaWAN stack. Its a planned feature but I am afraid I cannot provide any specific timeframe on when it would be added.

You could also use the raw LoRa mode of our devices. This allows you to directly communicate between devices using LoRa. If the devices are strictly RX only and TX only this could work quite well.

[bmarkus]

@seb said in LoPy broadcasting network:

If you are using LoRaWAN you can achieve this using downlink messages, the catch it the devices only get these downlink messages after then send something to the network.

It is true for Class-A devices, but not for Class-C mentioned in the opening post.

Even you can have the same DevAddr and encryption key set in multiple devices to get kind of multicast features if all devices covered by the same GW.

[derchris]

Thanks for the quick reply. But it sounds strange that a downlink message is only possible after an uplink message. That might result in too much traffic in the bands, I guess. What about multicasting?

[seb]

Hi,

If you are using LoRaWAN you can achieve this using downlink messages, the catch it the devices only get these downlink messages after then send something to the network. Using this you could put your nodes to sleep and then every 2s wake up and send some dummy data to the network, if there is downlink data this will be received, if there isn't then the node will not get anything.

Depending on what network you are using the interface to send these messages varies but most seem to use MQTT.