That’s what I meant ie I’ll change the code so it doesn’t do a join for every uplink transmission.
For general testing under these circumstances, ABP is much preferable but you need to turn off the Frame Counter on the TTN web console (or preserve it in your code).
Something else for me to learn about 
At present, the list of things to add to my “Getting started” docs is growing rather than being reduced as I make notes 
Off topic, someone else got caught by the DNS issue!
What does the “Confirmed” tickbox on the TTN page actually do? I’m guessing if you tick it then it continues to send it at every opportunity until it receives an ack from the node, and if you don’t it sends it once and once only. Is that about right?
Yes, that is correct but as there is no delivery guarantee, you can get your device / gateway / application in to a tailspin and burn up device battery with the additional transmissions and general mucking about.
Much better to put an id byte in to a downlink that is sent back, preferably tacked on the end of a normal uplink, that lets the application know it’s been received. If the change can be implied, like a change in uplink frequency, then the app could just look for that.
The real culprit in all of this is confirmed uplinks which is implemented in some stacks and not in others - the primary issue is that the gateway has to transmit the ACK and any gateway transmitting is not able to hear anything whilst that is going on. So you potentially burn device battery and take all other devices off the network whilst listening for the ACK.
Much better to track Frame Counts at application level and if absolutely critical, create a downlink for a resend request. At which point I’ll explain why you need to step away from the LoRaWAN and go and play with GSM, NB-IOT, Satellite, carrier pigeon or some other technology - system critical isn’t what LoRaWAN is about and a flood of downlinks are a nightmare.
LoRa can be made to do system critical - as can any other transport mechanism. I use dual channel gateways for P2P - one chip is set to listen all the time with some Channel Activity Detect to cope with varying SF, the other chip can do so as well, but is available for transmission with a suitably socially-isolated antenna so it doesn’t blitz the first chip. Various levels of complicated code can then be invoked to manage transmission slots, counters, resend requests and so forth.
Thanks for this. I will need to study it carefully…
Could you explain a little more?
ABP means you aren’t using up your nonces with lots of OTAA join requests.
If the device doesn’t save it’s own frame counter, you’ll need to turn off checks on the device web console otherwise the network server will reject uplinks until the frame count is back in sync again.
As well as the official LoRaWAN spec, the non-product specific sections at https://www.thethingsnetwork.org/docs are hugely useful. For frame counters, see https://www.thethingsnetwork.org/docs/lorawan/security.html
1 Like
One question regarding downlinks
As nick above posted
while lora.nb_downlinks:
print('Received', lora.get_downlink()['data'].hex())
Is this a functionality only for the v2 firmware as i see its on the otaa_v3.py? Should i sent a specific HEX from TTN to get a pin trigger or something in my console or in cutecom thats its constantly connected to my node through GPIO uart pins?
Hi @panban ,
I don’t have a pHat currently setup here and I honestly havent tried that library.
But if your goal is to trigger a certain pin with a downlink message, you can send a downlink from the TTN V3 device console then see what will be printed in your terminal.
Take note that if you are operating in Class A, the downlink message wont be received unless you send an uplink.
Thanks for your prompt reply @carlrowan, by terminal you mean my Thonny Ide were i execute my code?
i already implemented the
while lora.nb_downlinks:
print('Received', lora.get_downlink()['data'].hex())
just before the lora.send() and lora.close() but no reception from the node in Thonny were the above script runs.
i get though
send package, but thats an uplink
Hmm. I think that part should be after the lora.send().
You send an uplink first before you wait for the downlink. Of course, assuming the downlink is already on queue from the TTN consol. If there is no downlink in the waiting list to be sent to you, you will not receive anything.
Well for an unknown reason it seems to work now, i get the printed data on my thony IDE console.
What i want to know if by that is possible to trigger something through the node and run a script on the Raspberry Pi4
Also from the features " * Also adds 8 extra GPIO pins controllable via the UART including 2 pins which can read analogue sensors!" if possible by the same concept to turn on a led connected on top of the pHat
Hi @panban ,
Did you put your while downlink after the lora.send()? That could have fix it.
Do I understand it correctly that you want to turn-on or turn-off an LED via a command from the network server? That is possible. You can use the IO of RAK811 or the IO of the Raspberry Pi 4 itself. Have you tried GPIO manipulation with Rpi before? There are libraries to do that. Might be simpler than messing around the GPIO of RAK811.
I successfully received a down link in class A configuration and yes the while downling is after the lora.send() thank you for that.
While im thinking to to manipulate the Pi’s GPIO to turn on a lamp with the provided libraries i’ve found, instead of using the pHat IO’s. Just after the while lora.nb_downlinks: i’ll paste the appropriate command for trigger a particular pin.
Now i am after getting to class c mode receiving down links but i face a syntax error with my code. As in another thread here i get the error of Traceback ( Most recent call last): File "/home/pi/join_new.py", line 7 lora.class = 2: ^ SyntaxError:Invalid syntax
Already my node is in ‘class=2’ and theTTN application is configured for class c devices.
If i either use lora.class= or class= i get the same mistake