I’m working with a variant of the LMIC code sending data through a SX1276. I have a local Things indoor gateway. In the gateway log on the console I see a downlink immediately after each uplink. Looking at a downlink payload shows it contains MAC commands, presumably for ADR.
Do these ADR downlinks count towards to the daily fair use limit? If so, is there a way to disable them? I don’t believe that the LMIC code handles MAC commands - it if did process the ADR data, would the downlinks stop?
Apologies, wasn’t sure of the right category, thought generic node meant generic questions on any node.
I’m using a Semtech SX1276 connected via SPI to a Raspberry pi 4. My interest is in occasional uplinks, not downlinks. I don’t seem to be in control of these downlinks, they are sent by the gateway unprompted. The payload contains a DevStatusReq command and a LinkADRReq command (03 50 ff 00 01). If I handle the LinkADRReq for subsequent uplinks, will that prevent future downlinks?
I’ve performed an OTAA join for my device and stored the keys and other join data. Right now I’m looking at how it handles MAC commands. It may well not handle the ADR commands, if not I will fix it. Just like to know if that will prevent future downlinks after uplinks.
The harsh truth is that if you don’t know the LoRaWAN spec well enough to know the answer, you may find getting to grips with updating the code base to process the MAC commands quite a handful.
Reality is that that repro is so old that it’s almost like using semaphore flags instead of electricity.
As generally we find that using a Pi brings too many timing issues to the party to be a good solution - particularly with timing the Rx1 & 2 windows which are pretty essential for OTAA configuration, ADR, Link Check Requests etc. So I haven’t got a recommendation for the Pi beyond having a module on AT commands that can look after the LoRaWAN for you.
Why re-invent the wheel - if you are only interested in getting odd bits of data out of the RPi as Nick says go buy a module (where the LoRaStack is taken care of for you!) supporting AT type messaging - there are lots available and are relatively cheap (note use a LoRaWAN module not a LoRa radio module!). At this point posters often say , aahh! but I am keen to learn and do my own stack/variant, in which case to borrow the old Irishman to lost Tourist joke - I wouldnt start from here - RPi is not a good platform to lean how to code a LoRaWAN stack for ^above reasons noted.
I’m always keen to learn new things and to be honest have had no problems running this code on the Pi. It is not as though it is running a desktop or anything else. I’m certainly not trying to write my own stack, more understanding how this stack works, along with making some changes so it can run on other platforms as well (such as microcontrollers), by improving the logic/hardware interface.
Interested in the comment on the age of the code (2018). Has the LoRaWAN spec changed incompatibly in last three years so that this code is rendered invalid? There is plenty of code that I’ve written which is older than that and which is in daily use throughout the world.
I understand that I do not have 100% understanding of the LoRaWAN specification yet, I was hoping to learn a bit more with my original question. I apologise if that was inappropriate.
I think this continues to highlight how much you need to know.
Only since v3.1.0 from Jan 2020 has LMIC been Class A compliant and still had two further releases in May & Dec to fix issues. Before that it could only just about cope with ADR properly.
Your choice of platform and your legacy code running around the world (I have code 20+ years still being updated) is a bit of a side issue. If this is for your personal project, perhaps run your own copy of TTS or Chirpstack so your experiments don’t disrupt the community network. As for making changes to get it to run on microcontrollers, that is a very very well solved problem, but if you can take the latest release and port it to the Pi, that would actually be useful.
Having an ambition to get to 100% understanding is laudable but I am deafened by the sound of Mission Impossible music being played in my head so I’ll stop now.
Er, no, as it says, that’s an application that wraps up LMIC to make it easy for people to program on the list of microcontrollers in the Readme - the Pi being conspicuous in its absence.
Try:
There is a very good reason that it’s for the Arduino and that there isn’t much up to date for Pi …
Thanks for the pointer to this code. I had not realised that the other code I was looking at was quite broken!
I’ve made a Raspberry Pi version of the hal.cpp code and it is working well - I am receiving Join accepts and other downlinks. And I am no longer getting a downlink for each uplink. No changes were required in the rest of the code.
Of course I will not be using the Pi version for anything permanent - it is a learning tool and I will use it to save the keys from a join for later use in a sx1276 wired to a Pico microncontroller.
As long as it’s behaving within the normal boundaries of a typical device, go for it.
The only reason for not recommending a Pi is that some think running a full GUI, watching YouTube and running a device should be 100%.
So if you care to share with an appropriate message about system load, I’m sure others will make good use of it. I personally use a AT based module so I can run a full GUI, watch YouTube and run a device at 100%!
