LoRa Node pHat for Pi - question about join-otaa

I’ve not had any issues with the current RAK811 firmware on both ABP and OTAA talking to a wide range of the gateways I have, some of which have no RAK elements in them at all. I also have my own hand-made nodes that I’ve programmed talking to RAK gateways.

If you don’t have control over the gateway but it appears publicly on TTN map, then it can be reasonably assumed that it’s OK. Where are you based?

I’d setup an ABP node on TTN and then get up close to the gateway (1km or less in a city, 5km or less in the open), use the RAK serial tool to configure and send some packets and monitor the TTN console at the same time.

Thanks. I’m in Milton Keynes, UK. There is a gateway at J14 of the M1 (named: gateway-2), which is the one I’m hoping to reach. I’m probably not close enough, given that it’s indoors. At the moment I’m trying a join-otaa command which is timing out. If you were able to provide something a little more step-by-step in relation to your last paragraph, I’d be really grateful. Thanks and best wishes.

The J14 gateway is a RAK833 on a Pi setup which uses a small piece of wet string as a starter antenna: https://uk.pi-supply.com/products/ipex-ufl-coil-spring-antenna-for-rak833 - and they have to remember to wet the string when it dries out.

These are absolutely fine for indoor work but, in context, my house setup is the same kit, a RAK833 on Pi with that antenna which is in the front room and nothing I do in my office with a test node can be heard by it. The office is at the end of the garden, so we are talking 15m, two brick walls & two sorts of French windows, not exactly a huge distance but these antennas aren’t really designed for gateways.

I very much doubt the location is exactly J14 as the unit isn’t an outdoor gateway. So you may find that you have to track down the property it is in and park outside to get a result.

Whereas the gateway at the south end of MK is an outdoor model with an actual antenna that can only feasibly be mounted outside as it is at 5m (should say 97m as it’s meant to be altitude above sea level). Given the proximity of Bletchley, if I was a betting man, I’d posit that this is a radio amateur’s setup - if they have a 1m glass fibre antenna AND they have multiple other antennas, you may be able to ask for help - standing 2m apart, naturally. Or go to Bletchley to the RSGB museum and ask for help.

In summary, I’d drive south and if you’ve got the setup done as per documentation for the Pi HAT and TTN, OTAA will be fine - I just use ABP as a sledge hammer route as it doesn’t have to mess about with all the join handshaking that you’ve observed.

At the very worst, I can sell you a RAK7246 gateway :wink:

Thank you. Useful to know about the limited range of your house setup, shame the Things Network map doesn’t give some indication of range. I’ve been to the coachway at J14 this morning without any success. Anyway, great minds think alike: I had spotted the more “substantial” setup near Bletchley and I plan to give that a go early next week. I’m interested in your comment that I may be able to get help from the owner of the antenna. Is there a means to make contact (other than trying to spot the antenna(s) and knocking on the door)? Thank you again for all your help.

That’s what https://ttnmapper.org does for us - but someone has to map. Sadly there is no realistic way for TTN map to know what the coverage a gateway may have, particularly if they haven’t entered an antenna spec.

You could bob in to the RSGB museum at Bletchley and see if they know anyone who’s playing with LoRa.

I went to Bletchley this morning to try out the setup there. I had SOME success! I parked up in the area where the gateway is marked on the map and ran my program (which does an otaa_join command and then a send command). The program timed out, as usual, after the join command (which I take to mean that the join wasn’t successful). HOWEVER, watching my account in the thing network while the join was going on, I could actually see each of the individual join attempts acros the five minutes as “Data” in the GUI. It was hard to take it all in so I decided to do a few tests and analyse the results at home. Annoyingly, now I’m home, all the data seems to have gone from my account. The only way I know I didn’t dream it is that the staus now says “X hours ago” instead of “Never Seen”, which is what it said until this morning. Do you know why the data disappeared from my account so quickly?

I seem to remember that for each individual join transmission, you could open it up and see the spreading factor, the coding rate, the rssi and lots of other information, which I was hoping to analyse at home. That would all have been very interesting. Also, there was an address of some sort which was changing on each transmission. What I’d really like to know, though, is why the RAK811 didn’t return a “yes, I’ve joined successfully” to the Pi. This would have allowed my program to move on and actually send a message. The join attempts were clearly getting through the gateway to the things network. What could stop them being considered a valid join?

Many thanks for your help.
Andrew

PS The gateway at M1 J14 seems to have been removed from the map!

My understanding is that TTN does not store your data at all. Rather it is designed to simply pass it on to whatever you have configured to receive it, for example something you’ve subscribed to the MQTT feed.

The only reason it appears to be storing when you are on the web page is that the packets are actually getting stored up in your web browser. Force reload the page and they’d probably be gone.

OK, thanks. That’s very helpful. I’m not aware of the MQTT feed, though. Are you able to point me in the right direction for that and how to use it?

Out of interest, if I wasn’t looking at the Things Network website at the moment when the message came in, how would I know that I’d received a message?

Thank you for your help.

All the instructions are on TTN website but you will need a machine on the internet to receive the messages.

You wouldn’t beyond the last seen info - you’d configure TTN to relay the message - you may want to look at the Data Storage integration as the simplest. However, that won’t show any of the meta info you want to see, so the HTTP integration is a possibility - but again, needs a machine on the internet to receive it.

As Chris says, you can see what’s going on in your web browser but it doesn’t persist, so don’t close the page. The nature of OTAA is that an address is assigned on join.

Are you using the Pi-Supply module and if so, are you using the supplied Python script without any modification beyond adding your AppEUI and AppKey?

FWIW I’m not sure if TTN will report joint attempts (or resulting accepts) via MQTT.

Generally the MQTT feed would be for application data.

While it could be useful to have OTAA info passed through, I don’t know that it is.

At a bare level of trying to get things to work at all, especially if you do not have your own gateway or any nearby to conveniently use for attempts, you may want to look into ABP instead of OTAA.

Thank you. In terms of monitoring the data, I’ll study that in more detail later. To answer your question about my code, I followed this set of instructions:
https://learn.pi-supply.com/make/getting-started-with-the-raspberry-pi-lora-node-phat/

My code looks like this:

#!/usr/bin/env python3
from rak811 import Mode, Rak811
import time

lora = Rak811()
print(“1”)
lora.hard_reset()
print(“2”)
lora.mode = Mode.LoRaWan
print(“3”)
lora.band = ‘EU868’
print(“4”)
lora.set_config(dev_eui=‘35xxxxxxxxxxxx08’,
app_eui=‘70xxxxxxxxxxxx4D’,
app_key=‘0Exxxxxxxxxxxxxxxxxxxxxxxxxxxx45’)
print(“5”)
lora.join_otaa()
print(“6”)
lora.dr = 5
print(“7”)
lora.send(‘Hello World’)
print(“8”)
lora.close()

I added the print lines so I could easily see the progress. I see 1,2,3,4,5 than a long wait and a timeout.

I got the dev_eui using “rak811 get-config dev_eui”
I got the app_eui and the app_key from the TTN page for my device.
These three parameters are entered without spaces and with the single quotes.

Can you see anything that’s obviously wrong here? As mentioned previously, I could see that my transmissions were being received but I don’t think my join was accepted.

Thank you.

This is not in the instructions for OTAA or in the example given in the library.

If you want to do this, please ensure you have used the EUI that’s on the module - I have found that the RAK firmware can get somewhat discombobulated if given a made up one. RAK buy the dev EUI’s so you don’t have to, they start 60C5A8

As an old f*rt programmer, I’d definitely recommend changing your 1, 2, 3, 4 etc to what’s actually happening, so much clearer and you could copy & paste the line of the program above.

Once you have this working, you can look at exception handling for Python to catch any errors.

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!