Not quite sure what this means, but as the current firmware requires a string of hex characters, not a string that would define an array of bytes in C and the template has it has a string of hex characters, I’m pretty sure 0x70, 0xa3, 0xf5, 0x1E, 0xf0, 0x02, 0xF6, 0xE8 should be 70a3f51Ef002F6E8. Just like you typed in to the command line.
The GitHub code would only work with firmware that’s a couple of years old, certainly not the v3 firmware commands. Seems odd to ask people to downgrade rather than have them make it v3 compatible… When did you get your module?
Seconds or minutes - slow is relative - an OTAA join will take around 10 seconds all told, assuming it all works first time.
Hello Nick, i just got the module brand new from Pi Supplies shipped 5 days ag to work on an edge project.
Just asked you for the ttn_secrets_template.py as it has this instruction for applying th app_eui.
“This key should be in big endian format (or, since it is not really a
number but a block of memory, endianness does not really apply). In
practice, a key taken from the TTN console can be copied as-is.”
Well if i run the sudo python3 otaa.py it takes minutes to execute, i dunno if anything has to do with the GPIO/Uart side
That block of text applies to the App Key, not the EUI. And that block of text is just copied from other unrelated libraries and is a bit misleading when it says it can be copied “as-is” - the TTN Console defaults to showing it as a hex string, not a C array. The PyRak library passes the value directly on to the module without any processing, so it has to be a hex string. Just as you do with the command line. The command line calls the same code to operate.
That is glacially slow - I’ll see if I’ve still got a PiSupply HAT in it’s box from some I bought last year and see if I can replicate the situation.
Well im going to update the hex values as the TTN implies, in the mean time im playing around with the GPIO subject to tell if thats the reason. Often the device gets busy in the console as it gets too much time to execute/ often with timeout errors. By the way in the TTN data i can see the activations everynow and then.
one update, running the instructions you mentioned about hex format of the App_eui and app_key in hex running an otaa.py
Gave me the following:
Setup
Joining
Sending packets every minute - Interrupt to cancel loop
You can send downlinks from the TTN console
Send packet
Send packet
Setup and joining was instant, to the last send packet responoce in console was in between 7± minutes.
at+ uart in cutecom within raspian in /ttyAMA0 gave 115200 8 0 0 0. Dont know if i can tweak something there.
Huh? TTN doesn’t imply anything. TTN provides a number of ways of copying the data depending on the destination format.
This part of the discussion was derived from copying the EUI’s & keys as C byte arrays and not as a hex string. The values at the command line were working, albeit slowly, just use them.
The example script uplinks once a minute - does the TTN Console show them arriving every 60 second, even if the console takes a little while to refresh?
The CuteCom result is per spec, I’d personally not ‘tweak’ anything there - the library assumes those settings.
Nope, not even close to 60 seconds, the activation was 20 mins ago ( by the way, not a reception issue i guess as i have and running a rak5205 in the same room)
That may be the problem - if the gateway and devices are too close together, they can overload each others input stages, particularly the gateway as the concentrator has 8 channels to listen on and you can end up with cross-talk between channels that confuse the whole chipset.
So, as it’s stupidly easy to do, can you put some distance (10m) or a brick wall between them.
OK, to be clear, ANY radio devices need some separation.
So your RAK811 HAT and the gateway should be 10m apart or in different rooms.
This is part of a range of standard answers and as it’s a really easy thing to try, please do. Sometimes it fixes the majority of the problems instantly, like this:
Gateway is about 3-4 km away, we gone out of focus i think. Is just the slow in console and execution and hence a result in TTN. Could a newer firmware might be a solution?
It’s becoming obvious from some reports on the TTN forum that there is some networking & processing issues. You may want to come back to this tomorrow to give TTI a chance to sort things out.
Hopefully a RAK staffer can confirm, but I suspect setting the config resets the uplink frame counter.
So the command line you tried, it used the last join info & frame counter, sent the message and all was good.
Your code snippet doesn’t have a loop, are you running it multiple times before you get data uploaded? If so, then as you are developing, I’d turn off frame counter checks. This will give you more info:
I finally overcome most of the problems as range/coverage ones. While my python knowledge isn’t top notch im trying to sent something parsed out of a JSON file. How is the correct syntax on having an uplink after a print variable?
On line 9 i have my print function were it prints the output of a JSON file narrowed to what i need. How will i convey this at lora.send without the error of line 20?
You need to rethink your whole flow: that python program is trying to do an OTAA join each time it runs, which is a severe mistake.
You should be doing a join only once and then running with that - ideally for years, but at the very minimum until you make substantial configuration changes.
It’s also unclear what you are wanting to send from the json; message sizes in LoRaWAN are extremely limited, so you really can’t send JSON itself, but only a tiny amount of information extracted and condensed from it.
It’s not really clear if this radio scheme is going to be a solution for your needs. But if it is, you’re first going to need to modify your code (possibly including the inherited starting points, which seem insufficiently thought out for actual use) to persist the OTAA session details. Then you’re either going to need to modify things so that you can read those and use them, rather than start over.
You may also want to consider daemonizing this code and feeding it data via some IPC mechansim, but really you want to be persisting the OTAA session info to “disk” and not re-joining each time you restart the process, even if it is a relatively long lived daemon and not something newly invoked for each transmission.
Hello Chris, i would isolate the OTAA join everytime i’d like to sent something. Now im a bit in a blinded spot were im thinking this whole flow. Im parsing a JSON file and having a python list from it.
One sample is this {‘apple’: 19, ‘orange’: 2} a python list which i either have to make it a hex or a string. You can also see another sample above in the picture right above the traceback warning.
My issue here isn’t the rejoining but as im new in the pHat, whats the syntax to sent to TTN after rejoining. Bear in mind that everytime i reboot i should be join through OTAA.
Thanks anyway
No, you must not do that! OTAA joins are designed to be extremely infrequent; ideally a device would only do so once in its entire service life, or else only in situations which cannot be made recoverable by reasonable engineering.
If you’re not going to take time to understand how LoRaWAN works, this project is doomed.
There are reasons why using a pi as a LoRaWAN node is highly unusual, the result is you may not really find any applicable guidance which does so correctly.
One sample is this {‘apple’: 19, ‘orange’: 2}
Decide how many bits (or more crudely, bytes) are needed to encode the range of each value and concatenate them into a binary buffer, probably with struct.pack()
