I have a question for which I could not find an answer here or on the net. Hope someone knows.
Thanks
You want to search again as this subject has come up before. The answer is no, it can not be done, look for the previous discussion for reasons why not. (Technically you can register it but it will not work on multiple networks)
Many thanks,
I think that, technically, it is possible to have one device (same DevEUI) registered on different networks, as Iâve done that without problems. However, I understand that it makes no sense and that it is not recommended at all. I am still not sure why. I was hoping that a device would be able to switch automatically from one network to another based on availability or signal strength, but it seems it does not work that way.
So now I am keeping my devices on one single network only.
If you put two postal addresses on an envelope, how does the post office know where to send it?
Despite not being physical, this âletterâ can only be delivered to one place.
And before you ask, no, there is NOTHING in the spec or any way of subverting the whole infrastructure to allow it to be delivered to multiple servers.
And even then, youâd have to use ABP because the sessions on OTAA canât be duplicated.
But, and Iâd need to see some code samples before supporting this endeavour as the coding is going to be a baptism of fire for all participants, you could have it switch sessions between different providers so it transmits for one network setup and then switches over to do the same for another - you could even do three or more. But this can of worms also leads to checking signal strength which is about downlinks which arenât a good thing and youâd not want puppies on multiple networks to be harmed. And it pre-supposes your node is moving. Or you canât add to gateway coverage. So itâs a huge workaround for the love of an extra gateway here & there.
The answer is yes, you can use any number of networks. The strategy I use is the store credentials for the Helium network and The Things network, and cycle through them on each transmission. So my transmissions alternate between each network on each transmission. Same logic can be extended to more networks. Each transmission can be received on one network only.
That is not using a standard LoRaWAN stack I assume because you need to switch devaddr and keys for the different networks. And keep track of counters and transmission parameters like the frequency plans and spreading factor and transmission power to be used.
What stack are you using and what did you modify to achieve this?
The state-saving capabilities added to LMiC to support the ESP32âs forgetfullness in low power sleep would accomplish about 90% of what is needed.
Where more thought would be necessary would be keeping the duty cycle and channel usage accounting contiguous even as the network state of a variety of âvirtual devicesâ rotates through.
Thatâs a mighty fine answer, totally correct, we know youâve done it but lacking any context for anyone reading it. For others reading along, @MedadNewman flies high altitude balloons that go around the world and he is at one of the UKâs premier science & electronics universities. As I said above, itâs possible but the code needs to be written and that is where it gets interesting. Itâs sort of in the territory of âif you have to ask, youâre not readyâ.
yes the stack is quite significantly modified specifically for high altitude ballooning. Its based on a fork off the semtech loramac-node code and can be found here: GitHub - ImperialSpaceSociety/LoRaMac-node: Reference implementation and documentation of a LoRa network node..
The device only uses ABP activation for all networks. Helium only allows OTAA activation, but I do a join on the ground and extract the network session keys which are then used as if its an ABP device. I have an option to send a downlink to the end-node to change the network session keys. Since I use 2 networks, in the instance the keys become invalid on one, I send up new keys on the other network!
The only parameters that are persisted in non-volatile memory is the frame count and network session keys for each device registration(28 in total). This is not lorawan compliant as there are lots of other parameters that have to be persisted. Persisting all the parameters for each device registration is not feasible due because it requires more than 1kb of EEPROM space per device registration.
I donât think the ordinary LoRawan user would ever go this extent to make things work!
Dont forget that in many territories there are Duty Cycle and or Dwell Time parameters limited by law - if doing such switching you need to also ensure Tx activity is tracked across all network usage and across all operating states of the device as the limits are applied per Txâing device not per network so FUP for any network not withstanding you will be able to feed data into either network far less often than if just servicing the node through one networkâŚalso if breaking/pushing up to the limits on one network irrespective of the fact using the other network may then become illegal it would certainly be considered anti-social as LoRaWAN is a broadcast technology where the GWâs for both networks receive all transmitted messages in range even the ones not intended for a given network as a result of change in Tx state to target the alternate networkâŚjust saying!
Ah, high altitude balloons with a line of sight to many many gateways and âparallelâ transmissions for multiple networks all using the same frequency band. Why am I hoping there wonât be many launches of balloonsâŚ
Donât worry, itâs as hard as LoRaWAN and you donât get your device back, so the intersection of people doing this is very very small.