now that V2 is dead and the dev block address 2601* my devices use are also moved, I thought I could give my devices that worked well for two years in V2 a chance to join the new V3 world.
Unfortunately the guides I saw here never fully applied to my device: I don’t have a gateway and I don’t want to reprogram them with a new address, if possible. The gateways my devices usually reach are still around and there are a few more with a v3 in the name. So I just took a chance and registered one in the V3 console with all parameters I could gather from the docs here.
Unfortunately there is “no activity yet”. The device does send as always, just verified with a SDR stick.
DevAddr, NwkSKey, AppSKey are the same as before in V2 (obviously).
Server is eu1.cloud.thethings.network.
The following should represent what the device uses and how it was configured in V2. But maybe I made a mistake?
The LoRaWAN.c is the problem here - it’s such a cut down version that it’s likely to be sending something that’s just a bit off causing the Network Server to drop it.
Ideally you’d need to check that the gateways in your area are hearing the device so we can confirm that it is being transferred to the NS.
I suspect your LoRaWAN version is a bit too high as well so you may want to try 1.0.1.
But overall, like the TinyLoRa stack discussions you can find on here, there are going to be challenges ahead.
I already tried all version levels and gave each some hours or so to get through, until I found the place in the docs where it said TTN V2 had used V1.0.2.
So since the device and its firmware did not change, and there is no obvious configuration mistake, it is a breaking implementation change between TTN V2 and V3. Can happen, in the end The Things Industries can do whatever they like with their stuff.
I could now try to improve the lorawan code, but since I cannot see any error messages that would be stabbing in the dark. Not fun and not productive. Also difficult, because with 16kB flash you can’t add much. Maybe I could invest in a gateway and see why it rejects the packets or if they are filtered out at yet another level. A too expensive experiment for my taste.
I think I’ll just let it rest and maybe reuse the devices for my LoRa-no-WAN-network where I have full control over what happens.
Well, yes, but in this instance they chose to make TTS more compliant with the internationally agreed specification for LoRaWAN - nothing was done ‘just because’.
The gateway is just an electrical energy format convertor - as long as the LoRa signal starts with the right set of numbers (the public network ID) and the whole lot adds up ie, it’s CRC is correct, it passes it on to the network server. So having a gateway will likely show you that the gateway is hearing the uplinks and passing it on, but if it’s not making it through the Network Server it won’t show any debug on the Application console so you won’t be any better off.
Well, probably good for them and obviously bad for me. V2 was compliant with my device and V3 is not.
Of course I am aware that I do not implement the full standard, but I read the various LoRaWAN documents and versions very carefully. While it requires clients to implement MAC commands, which I dont, there is nowhere a requirement for servers to reject such devices. So it is a business decision - I won’t fight windmills. Case closed.
Sorry, english is not my first language, maybe that is the reason both statements have the same meaning for me. But I see why you may be a bit picky about it, so agreed, my device is no longer acceptable.
Wording again? I dont really care, would ignored be better? Fact is, V3 does not show a reaction to my device.
If I could see where my device was just acceptable in V2 and I need to change the implementation to make it acceptable again in V3 I might not see it as ignoring. But as I said, I read the specs carefully, compared what my code does and did not find a technical reason to get no reaction at all in the console. That does not mean there is none, but it is more or less all I can do, except asking for help here. And that did lead to the confirmation that the config seems ok and my lorawan implementation is not good enough. I am thankful for that, but so far I looked at “newer” implementations to functionally compare what they send and I dont. Not finished, but so far no result. At least I have a bit hope again
I don’t have contact to local gateway owners. The gateways my devices reached are between 4 and 12km away and they don’t seem to publish contact data, just the ID. Could try to do some research here. Reported signal strength was -110 +/- 5 dBm
I could get access to a gateway - the one I started the LoraWAN journey, but that is now deployed over 100km away. I guess that is not helping.
I also could program a device to receive (and decode if needed) LoraWAN on a single channel and config (from those my devices use). So I could show what a gateway could receive, including timing, if close enough. I could do this on a raspberry pi or pico, esp32 or 8266, some STM32 chips, or probably any other µC that supports SPI, if you have a suggestion for existing code. Otherwise I would start with my LoraGW firmware and add higher level protocol stuff as needed.
Never heard of the V2 settings downloader. Is it possible to still get the V2 settings of my devices? I thought that is out of reach with the V2 console shut down. I know I didn’t do anything fancy or exotic, but this way I could show it in detail.
For community members who missed the warnings about the shutdown of TTN V2 we’ve been sending since February, for those who didn’t manage to migrate their devices before the migration deadline of September 30, for those who didn’t make it to the December 1 traffic API shutdown, and even for those who didn’t export their devices before the final shutdown of V2 on December 7, we are happy to announce our new The Things Network V2 Take-Out Tool. https://v2takeout.thethingsnetwork.org/ After signi…
Nice tool! So people can retrieve their keys and IDs and some meta infos if they dont have them anymore.
I still have them and I think @descartes meant protocol config stuff. I dont see how this can help me or him to find protocol- or settings-incompatibilities.
It’s to verify your EUI’s and keys - because as I said above, if it’s not appearing on the device console, then one of the issues is likely to be an EUI error
Should I send you those keys as PM? I just doublechecked they are the same on the device and in the console (more like quadruplechecked ), but hey…
I don’t think EUIs are involved with ABP devices (at least on user level) - I don’t have them on the device and there is no way to configure them in TTN (as far as I can see) and it wouldn’t make sense to do it as far as I understand the encryption process. But they are listed in the takeout tool, so I could send them as well.
Before this gets too protracted and I end up being silly & wiring a small STM board to an RFM to run your code, how many of these devices are we talking about and can they be replaced with something running a known good MAC?
rebuilding this would be overkill, but thanks for thinking about it!
I only have built 4 devices so far (material for 10 more) and only two of them are difficult to retrieve for reprogramming.
If you tell me the config is ok and dont see an obvious known to not work pattern from your experience then I need to reprogram them anyways and the most effective thing is for me to compare my code with known to work code.
The code base you have is so basic it hardly qualifies as a LoRaWAN MAC, in reality it never really did, it just bunged the right radio noise in to the ether that aligned with an ABP transmission.
Ideetron’s more recent implementations (which that code is based on) is now a dozen or so files, last updated 2018. Recent LMIC versions are 70+ files, albeit with support for different channel plans & hardware, but none the less, not a quick migration.
Lee has moved on considerably since he ported the one-file Ideetron implementation, using an STM32L051 and the recently deprecated Classic LMIC which in, it’s final incarnation was mostly compliant with downlinks, MAC commands and OTAA. See https://www.iot-lab.org/blog/370/. With some finessing, his new hardware should do MCCI LMIC which is very compliant.
Your STM32L011 with only 16KB Flash & 2KB of memory is too small to accommodate even Classic LMIC which is typically used on an ATmega328 aka Arduino Uno/Nano/ProMini but even those are a struggle to get MCCI LMIC to fit.
So, bottom line would be that you swap your MCU to a STM32L031F6 which has enough flash and plenty of RAM and the same footprint and benefit from being bang up to date with your LoRaWAN implementation.
Good advice in general. I also looked into using STM32L051 or maybe L031 to have more headroom. At least on paper they might be comparable to the L011 regarding power consumption (which is the most important aspect for me) - I have not tested them yet, because it seems they are better used as an investment object since over a year now and most likely next year, too. I payed ~60ct per chip and got them in a week or two back then. Now the L051s cost over 4€ with a delivery date in 48 weeks - but no promises. I wonder what price I could get If I sell mine with guaranteed immediate delivery right now
And still, it was the perfect fit to get the job done for me. Granted, LoRaWAN was more even back then and it grew larger with every release. That’s why I didn’t try to migrate earlier - I figured it has outgrown my usecase and wont work anymore. I dont need or want all the fancy new features that are all about automatic reconfigurations. 70 files for sending some bytes of data home via a gateway? Wow!. Not much traffic around here, not much change in infrastructure. Static reconfiguring via a web page now and then would be good enough for me. Reduces complexity → saves energy (and cost if that would be a concern). But that’s not how it works … so far.
Thanks for the link to Leo Korbees project - didn’t have seen his latest improvements yet.
As you can see from the long delay, I followed your advice and stopped trying
And in the end, that solved it!
7 days ago, TTN started sending frames to my http integration.
I noticed today and adapted the decoder and my webserver to the new json structure.
→ Finally back in business
Thanks for your support, I’m really glad it works now.
), but hey…
