Searching for RN2483

[Wiki]

Hi,

I just want to start in Lora/TTN and am looking for a RN2483 module which is useful for ESPEasy.

Having a look at Ali, I can't find a RN2483 868MHz module. Where do I get such a module and is there anywhere a wiring diagram?

[TD-er]

I have made a board myself for this module.
It isn't a complex schematic, only problem is that the module really needs a PCB as you can't really wire it using pins and a pinheader.

[chemmex]

I have made a board myself for this module.
It isn't a complex schematic, only problem is that the module really needs a PCB as you can't really wire it using pins and a pinheader.

I'm afraid, the RN2483 are hardly avaliable nowadays. Even by the time you added the Lora/TTN controller to the ESPEasy, they were very hard to find.

However, there is a number of LoraWAN modules from E-Byte, RAK or Seeed Studio with LoraWAN stack embedded, maybe there is a chance to refactor the controller to support a wide range of modules?

[TD-er]

I have plans on adding the bare SX12xx chips using LMIC, which are present on quite a few cheap Lilygo boards.
The reason I started with the RN2483 is simply because that one has a certified LoRaWAN stack.
Lots and lots of LMIC versions are not standards-compliant.

Also I could buy a handful of those modules from Jac (Kersing) whom I know and lives near me

[chemmex]

Definitely a good idea. Are you planning to keep it in the same controller code or add a new one?

[TD-er]

Since it will be using a completely different library, it will be a different controller.
However there is still a lot of code to be shared, for example the JavaScript decoder on the TTN servers etc. will remain the same.
Only some cosmetic updates like newly added plugins and extra hardware definitions.

[Wiki]

Hi,

looks like I have to wait a little bit. Is there any time schedule for support of the nowadays commonly used SX12xx chips?
I'm not in hurry, just starting. And before spending my small money on something like helxxxc which I have to program by myself I would be patient.

Here around are some efforts to push TTN resp. NodeSH, I've installed already a running gateway (gift from a friend) to participate in this rush.

[TD-er]

Just FYI.
All *) LoRa/LoRaWAN boards/modules will be using those SX12xx chips from Semtech, even the RN2483 internally is using one.
Only difference is that it does have a MCU along with it with a certified LoRaWAN stack running.
The LoRa radio protocol is dealt with by those SX12xx chips.

So all I need to do is implement the LoRaWAN stack using LMIC.

The difference between LoRa and LoRaWAN is the added layers on top of the radio protocol.
A bit like running TCP over WiFi. (only way more internal layers of encryption used in LoRaWAN)

*)
I know nowadays there are some other radio modules which also can mimick the LoRa 'chirping', though I'm not sure those are allowed to be called LoRa.
I know it used to be protected by patents, but I'm not sure if the LoRa name is also trademarked.



There is however a rather big issue with LMIC.
You can't store the current 'state' of the connection.
Meaning you either must perform a new OTAA when you reboot, or take some counter measures to make sure new packets will be accepted by the gateway/network.

- Disable frame count checks (rather insecure, as it allows a replay attack)
- Store frame count and nonce in some non-volatile storage, and/or make some 'jump' in frame count to make sure you're using a count which was not used before.

And there are some other issues as wel.
TTN requires you to register an unique MAC address. They can also generate one for you, but when you need more you may have to pay.
When using a software LoRaWAN stack, you don't have an unique address. Though you can be 'creative' of course
There are other 'strange' decisions made by TTN regarding those addresses, which are not specific to a software LoRaWAN stack.

[Wiki]

Thanks for the explanation.

Am I wrong if I guess that the FCnt could be stored in the RTC memory like the Dummy values? Should survive the reboot and deep sleep, so performing a new OTAA should only be needed after power loss?

[TD-er]

Yep, we could keep stuff in RTC memory, or even add some EEPROM (or on flash) to store values to every N messages.
So we can jump to the next "modulo-N" frame count value after power loss.