I am developing a LoRaWAN node with my own hardware and firmware.
I am now testing the transmission of uplinks.
On the gateway, I can see each uplink in the ‘live traffic’,
On the application server, I am missing some of the frames, ie. not every frame seen on the gateway seems to be accepted by the LNS.
Is there a way to monitor on the LNS why it is rejecting those frames ?
I’ve looked at live traffic, setting verbose to ‘on’ but I still have no clue why the frames are dropped.
Depends, mostly not.
What MCU & radio are you using?
What LoRaWAN MAC / stack / firmware are you using?
What authentication method to the LNS are you using (ABP or OTAA)?
What gateway are you using?
How is it connected to the internet?
The more information, the more we can help first time. Otherwise it turns in to drip-feed and can take days.
Similar issues have (only) occasionaly been reported in the past - to investigate we need details and logs/captures showing the problem so we get a better picture of what is happening. Once into the backend there is little scope for loss I believe, are you looking at the console views and comparing or looking at actual stored application/device data - storage integration or better yet in your own off server database/store? Are you decoding on the TTN back end or off-loading to own server and decoding there? (Decode can fail if server load high or your decoder takes too long - its a nice to have not a service to be relied on). Has there always been a problem for you or have you seen a recent change to behaviour?.. Details please as Nick asks…
MCU = STM32WLE, it has an SX1262 inside (if you are interested, here is a link to the hardware
The LoRaWAN stack is my own.
I’m using ABP (no need for OTAA at this time for our application)
Gateway is the The Things Indoor Gateway, connected with WiFi to my home’s AP
Gateway is provisioned in TTN Community Edition.
So all of this is working, as I have a DataCake dashboard connected to the LNS and my sensor data is showing there.
But looking at the timestamps on the gateway (Gateways → Live data) and on the application (Applications → Live data), I see that some packets are received by the gateway, but not appearing in the application.
I can imagine there are several possible reasons for that:
- an error in the LoRaWAN packet, wrong header, wrong MIC,
- maybe the LNS enforces dutycycle limitations and drops packets which exceed that…
One thing which is for sure not the cause is an error in the uplinkFrameCount, as I can see it nicely incrementing on the gateway.
So in order to find the root cause, I’d like to see some logs on what happened when the LNS received a packet from the gateway…
Here are two screenshots of how the traffic is different on gateway vs application server
- packet from 13:17:34 is shown correctly on both
- packet from 13:19:34 is only shown on gateway
- packet from 13:21:34 is only shown on gateway
- packet from 13:23:34 is shown correctly on both
The problem is easy to reproduce, ie. it happens quite often.
Thanks for your tips and help.
P
Note : the Join traffic seen on the gateway is not mine… it’s from another device in the neighbourhood… My test-device is the 260B3B92
First, do you observe the FUP?
Second, take a look at the downlinks to check why you are burning gateway transmit time like no tomorrow.
Third, why implement another stack when there are proven versions that adhere to the standard (and took a lot of effort to get right)
Which MAC commands have you implemented so that your device will respond appropriately to requests from the LNS to ensure good community use of the network?
Any reason why you reinvented this very complex wheel?
What’s wrong with the STM32CubeMX package or the LMIC or the STM32duino version of LoRaMac-node?
The reason I’m being pokey here is that we are in an almost impossible to debug situation as pretty much anything could be going on inside your code.
It’s not like the STM32WL is a constrained device - plenty of room for the stacks that are on offer and so much easier to implement than get in to the weeds of writing your own.
I have STM32WL modules literally scattered around me and I use LoRaMac-node + LMIC on a daily basis on a number of devices of my own so I do have an inkling of the difference between DIY stack and implementing a known good one.
OTAA is recommended for a very very good reason.
Very probably - but there are no logs for you to debug this.
Now you come to mention it, you are in breach of the Fair Use Policy, not just on the send but on what looks like a downlink per uplink Please throttle back your sends as a matter of urgency - when testing something this complex it won’t fix itself via blunt force trauma a push to send suffices.
For ABP the classic is the frame counters. In this situation it’s unlikely to be as they are incrementing. So the refined answer is no, there are no further logs for us to see. If you want to write your own stack, how about doing it against a copy of TTS OS on a local server, then you can poke under the hood as much as you like.
Ok, thanks for all these good hints.
I spent a lot of time investigating the LoraMac from Semtech/ST.
Personally I disagree that it’s solid and easy to reuse.
I will set up my own TTS to get some more logging while building and testing the LoRaWAN implementation.
I’ve ported loramac-node to a new controller and am working on a second one and while it does take time to get familiar with the code, it is the best choice if you need a sx1262 compatible stack in my opinion. At least it is the only one I know to pass the pre verification tests (and I know it passes because I ran those tests on that stack).
The vast majority of the commercial devices use it.
It isn’t the best signposted code in the world, but then LoRaWAN has many many nuances, particularly when you get in to multi-region support, so there is a blizzard of code to wade through.
Apart from settings which you may need to bookmark to come back to them quickly, the principle item is the payload which is all laid out in one place. I use an empty STM32 project to code up & test sensors and then migrate them across to the LoRaWAN project and reference them from the payload function.
I can make it do most things, it takes serious skills from people like @kersing, who not content with writing the best gateway software, ports the code base to other devices.
And as Jac says, if you don’t mess with the internals too much, it gets you a long way towards certification.
Overall there’s going to be much more assistance with implementing LMn or LMIC than being able to help debug your own stack.
4 posts were split to a new topic: ABP device packets in gateway view but not arriving at application