LoRa Node pHat for Pi - question about join-otaa

Thank you again for your response. The reason I included the dev_eui line is that it’s in the code at the pi-supply instruction page I referenced (https://learn.pi-supply.com/make/getting-started-with-the-raspberry-pi-lora-node-phat/). The value I used came from querying my pHat using the command “rak811 get-config dev_eui”. I didn’t make it up, it genuinely starts with 35, ends with 08 and has 8 bytes, as shown in this screenshot:


Definitely doesn’t start 60C5A8, which is strange.
Any further thoughts?
Thanks again

Groan - so Pi-Supply recommend a library but then override it’s example. I’ll dig out my Pi-Supply RAK811 pHat and take it for another spin to see what I did.

I note on their website that the RAK811 doesn’t have the EUI printed on the module.

In the meanwhile, RAK may have move over to a new block of EUI’s but I’ll only know once I’ve looked at mine, one of which is still in its box so will have whatever it was shipped with.

I’ve dug out the unused pHat and followed the Pi-Supply instructions for OTAA with and without the Dev EUI being set in the code (as above). And I’ve tried the ABP instructions as well. All works.

As to the EUI’s, tracing through the history of the library, I can see that the firmware for the RAK811’s that have been shipped by Pi Supply up to now is older and therefore is likely to have different EUI’s. The ones I have start 32383335.

Driving to a location to try things out will be a pain - you need a laptop online and a way of getting the Pi up & running and knowing what it’s doing - but a more controlled test keeping the laptop online whilst you copy the results over.

Have you altered the aerial arrangement - the on-board one won’t be as good as using the IPEX coil antenna - you never know, with a window facing south Bletchley you may well get a signal through to the gateway without leaving home!

Thanks again.

So it seems we’ve ruled out the line in the code that sets the dev eui as the cause of the problem, which is progress.

The antenna I’m using is the one supplied with the pHat kit (the sma one). I have made the appropriate changes on the board to divert the signal to that antenna. As I mentioned, I saw all the raw join requests coming through on the TTN webpage while they were happening so I don’t think I have an antenna issue as such. Unless for some reason I can transmit but not receive (unlikely, I suspect).

The dev of the device starts 35343531.

I have now borrowed a second pHat and its dev eui starts 32383335 like yours does.

Unless you disagree, I think perhaps the best thing to try is to go back to Bletchley and:

  1. Try the new device, just in case. You never know!
  2. Try the old device again and somehow try to capture the packets (ie the raw join requests) received by the TTN website while I’m there such that they can be scrutinised later. Perhaps they will reveal what’s going on.

Thank you for all your support and for any comments you can offer on the above.

Excepting that you are transmitting on a teeny tiny antenna that’s being picked up by a honking great sensitive antenna which will then transmit at about the same power as your node, to be picked up by its teeny tiny antenna. So, just in case you’re sat in a Faraday cage, do this outside the car or any buildings and certainly away from the Bletchley RSGB shack with its many radio devices doing who knows what at any point in time. Also, you don’t know if the gateway is 100% - it could be transmitting on reduced power or on a laggy network that means it transmits the join acknowledge too late.

There’s not much more detail to be had from the TTN console join request - if it heard a valid one, it will send back the details. Ideally you want a gateway where you can see what it is doing - like receiving the join acknowledgement from TTN and transmitting that for the node to receive.

However, as you now have two nodes to try, I’d travel hopeful.

In the meanwhile, I now seem to have a use for about 200 PCB’s that ended up surplus to a project. I can make up a test-a-gateway node in a small box to help sanity check such situations …

Thanks again. I’ll try again sometime this week.

Just a thought. On the TTN page for my device there is a button against the dev_eui, the app_eui and the app-key to change the endianness of the bytes (msbyte first or lsbyte first). This has made me wonder: in what order should should these bytes be put into the python code? In all three cases I have put the most significant byte on the left, least significant byte on the right, no spaces. Could that be relevant?

I’ve only once had to swap from the default msb to using lsb for a particular software setup - if you just copied using the little clipboard button you should be good to go.

Once you have got a setup that works, it will be easier!

Hi, I’ve been back again this morning with two units and a few different antennas. Without exception, the join_otaa command times out after five minutes without completing. This means that my code never moves on to attempt to send my message. Instead it bombs out with a timeout error.

This screenshot shows (21 of) the 32 individual attempts to join.

This is the content of a typical individual attempt as reported temporarily on the data page of my TTN account:

“time”: “2020-05-28T08:29:51.157769039Z”,
“frequency”: 868.3,
“modulation”: “LORA”,
“data_rate”: “SF7BW125”,
“coding_rate”: “4/5”,
“gateways”: [
{
“gtw_id”: “eui-3133303738006200”,
“timestamp”: 3466614580,
“time”: “”,
“channel”: 1,
“rssi”: -78,
“snr”: 8.75
}
]

All 32 of the individual attempts that form a join_otaa command are getting through to the gateway. -78dBm is a good strong RSSI, so there’s plenty of signal in hand (and there should be - I’m right by the gateway!).

I can only see two possibilities:
(a) the gateway is not responding
(b) the gateway is responding but my devices aren’t picking it up.

(b) seems unlikely because my transmissions are getting through so well. The path loss, antenna gains, tx power are same in the downlink direction as in the (succesful) uplink direction so I’m struggling to believe its a lack-of-signal issue. So that leaves me with (a). Can you see anything in the screenshot or the captured data that suggests what might be wrong?

Thank you again.

Time to get my hands on your module - and I’ll send you a working module to test locally - see your messages.

Hello @aal7 did you ever manage to get this to work. I am the owner of the gateway that you are nearby and periodically google its id to see if it’s been used for anything interesting. Would be great to know if it has worked for you.

Cheers Greg

Hello @greglangford. Thank you for getting in touch. If you are the owner of the Newton Leys gateway then that’s fantastic because I’ve been hoping to talk to you! The short answer is no, I never got a message through that gateway. Monitoring my TTN account live while the join requests were happening, I could see the individual join requests, but it looked like they never suceeded because my device never moved on to send its “real” message. I tried twice at Newton Leys and the same thing happened both times. Subsequently I tried another gateway at Duston in Northampton, which was successful. If you have any thoughts as to what might be the isuue I’d love to hear from you. Best wishes.

Morning @aal7

I am actually not sure what could cause that, I have not tested it myself as another project came up since installing the gateway. At some point it has transmitted 282 messages randomly one weeked, I can’t remember what date but maybe that is when you were trying.

I just checked the configuration and it all looks valid according to the documentation on the things network website. I have also just updated the firmware so it might be worth another shot now?

I do periodically see traffic arriving mostly for other networks but the odd things network packets do arrive, mostly though they appear to be dropped with the message no brokers. I assume this is because whatever application has been configured for those devices is not responding correctly.

You are more than welcome to come and try the gateway again, id actually be really interested to see how far the range is on it as I have mounted it outdoors and up high on purpose to increase the range.

Cheers

Hi @greglangford. Thank you for this. When I had little success with my pHat at NL, I decided to purchase a commercial LoRa device to try. That should be here soon. I plan to return to NL with that and my pHat at some point. It would be great if we could hook up (even if it’s only by phone) when I do that test. Do you think that would be possible? Strangely, my original intention was to find out the range, but I never got a message through when parked right on the doorstep (according to the TTN map, anyway) so I never really did any range trials! By the way I wasn’t there on a weekend, so those 282 messages you saw probably weren’t me.

@aal7 sure that would be great, i will send you my number so we can co-ordinate when you decide to try the gateway again. I can even login to the TTN console and show you what is being received by the gateway if that helps at all?

@aal7 actually it seems I can’t send a message on this platform, drop me an email on greg [at] langford.me, change the brackets and at with the correct symbol just obscured it on here to stop bots picking it up.

That would imply the gateway is not connected to a TTN network server which would do the responding. The application server would pass the message on to the destination setup for it. Neither the application server nor the end users destination would provide a response to an uplink but the end users systems may chose to send a response as a downlink message which would happen later on.

Mostly gateways are only connected to one network server.

Hello to all, i’ve played in the past with a rak5205 self contained module and im pretty much have some experience with the ttn, dev_eui, otaa etc.
In the meantime i’ve purchased a pHat on top of a Pi4B.

Already had made the hello world example and executed it with a SETUP responce to the console. Though my node never had seem a connection in TTN. Further down to the example i also installed the repo and added the keys in sudo nano ttn_secrets_template.py and the copied them to cp ttn_secrets_template.py ttn_secrets.py.


As im new to this approach, does the above screenshot in big endian format is a good input for quotes and brackets, seems legit? Also how the above is relevant to the Hello world example, there seems to add only plain numbers for eui and keys from TTN.

In the end when i execute the sudo python3 otaa.py
pi@raspberrypi:~/pyrak811/examples $ sudo python3 otaa.py
Setup
Traceback (most recent call last):
File “otaa.py”, line 34, in
lora.mode = Mode.LoRaWan
File “/usr/local/lib/python3.7/dist-packages/rak811/rak811.py”, line 289, in mode
self._send_command(‘mode={0}’.format(value))
File “/usr/local/lib/python3.7/dist-packages/rak811/rak811.py”, line 224, in _send_command
response = self._serial.get_response()
File “/usr/local/lib/python3.7/dist-packages/rak811/serial.py”, line 140, in get_response
‘Timeout while waiting for response’
rak811.serial.Rak811TimeoutError: Timeout while waiting for response

One last the sticker ontop the pcb has a different eui than what reports with the rak811 get-config dev_eui
Firmware OK2.0.3.0␍␊ under cutecom

What am i doing wrong?

It’s incredibly hard to read - if it’s text, why not copy & paste it here?

It does look like you’ve put in a hex array and my local dev copy just has it as a hex string - what was the format when you opened the original template file?

And how did you install it.

The GitHub repros for RAK811 Python support are way out of date even though they are appear to be up to date. The original AmedeeBulle and PiSupply developers must have some seriously old firmware and Amedee uploaded the AT command pdf from two years ago just this Sept.

Consequently the command being set on line 289 is no longer at+mode=0 but should be at+set_config=lora:work_mode:0.

Even with this change, other commands will probably need changing and if it’s like the RAK Arduino library, it will stop at this point whilst the module restarts.

Odd thing is, I’ve clearly run this on a Pi, I guess it was about a year back before the time of the Great Firmware Update.

“”“Application EUI.
This EUI must be in big-endian format, so most-significant-byte
first.
For TTN issued EUIs the first bytes should be 0x70, 0xB3, 0xD5.
“””
APP_EUI = ‘{ 0x70, 0xa3, 0xf5, 0x1E, 0xf0, 0x02, 0xF6, 0xE8 }’

“”“Application key.
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.
“””
APP_KEY = ‘{ 0x78, 0xc3, 0x1F, 0xf3, 0x32, 0x3c, 0x19, 0xc4, 0xE6, 0x63, 0x62, 0x63, 0xB6, 0x2A, 0x73, 0x98 }’

Should be of this format in the section were you edit the ttn_secrets_template.py?
Should i update the firmware, got a responce in github of not doing so as it will break the code current firmware is based on.
I actually made it working with the following out of AmedeeBulle example and not pi supply one

rak811 -v reset lora
LoRa reset complete.
$ rak811 -v set-config app_eui=70B3D5xxxxxxxxxx app_key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
LoRaWan parameters set
$ rak811 -v join-otaa
Joined in OTAA mode

but i get a very slow response, i dunno if its an uart issue or a gpio re-config.