LoRa Node pHat for Pi - question about join-otaa

LPWAN Nodes
1

Hello,

I’ve recently bought a LoRa Node pHat for my raspberry pi. I’m told by the vendor that its firmware came from RAK wireless. I have noted that when I run a join-otaa command to join with over the air activation, that the transmissions form a very specific pattern. Most are ~75ms long. Eventually there’s one at double that duration (presumably the next spreading factor up?). A few more at ~75ms then one at four times that. A few more a ~75ms then one at eight times that. A few more at ~75ms then one at sixteen times that. Then stop. Is this procedure a defined LoRa method for joining OTAA or is it something that is specific to this (or perhaps all) RAK modules? Presumably it tries increasing spreading factors to increase the chances of getting through if the lower spreading factors have failed? Thanks for any light that can be spread on this.

2

That’s the sort of pattern of trying to make contact - do you have a gateway nearby that it could talk to?

3

Thank you. I think what I was really asking was: do all LoRa devices do it exactly like this (according to a LoRa spec) or is this a method that you have chosen for yourselves? If the former, I’d like to see the LoRa spec containing this info.

Am I correct that it is varying the spreading factor to achieve the different lengths of transmission?

There is a gateway locally but I suspect it’s just a bit too far from here for me to get through.

Best wishes.

4

@aal7,

Can you share which exactly is the product you are referring to and also provide a link to the firmware.
I was not aware we are selling a Rapberry Pi Node hat, we only have them as Concentrator modules.

Regards
Vladislav

5

Pi-Supply in the UK do a RAK811 on a Pi HAT.

@aal7, the join starts out with a high data rate to minimise air-time and works it’s way down until it makes contact or runs out of options. Technically, the spec suggests using a random sequence of DR, in practise it just makes more sense to start out with the shortest, most power friendly, rate.

Bearing in mind RAK are using v1.0.2, as are many others, here’s the PDF:

6

Thank you @nmcc for this explanation, and for the spec. If you could be so kind as to point out where the random sequence of DR is mentioned in the document I’d be really grateful - I haven’t managed to spot it. Thank you again for your help.

7

It’s a terse paragraph in the Join protocol section 6.2.3 but not explicit - it definitely says random frequencies and then says “a plurality of DR”.

What is the end goal here?

8

Just trying to understand, really. In particular, whether or not the join pattern exhibited by the RAK811 is likely to be duplicated by other LoRa devices. I’ve taken from what you’ve said that other devices will probably do something similar, but not necessarily exactly the same because the standard doesn’t mandate anything specific. Also whether I have any control of the RAK811’s join process because at the moment it won’t talk to the gateway. I had wondered if I could try a different spreading factor (before I understood that it’s trying different spreading factors itself anyway). The whole join process seems quite self-contained so I think I’m going to need a better antenna or to be closer to the gateway. Thanks for engaging - I appreciate it.

9

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.

10

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.

11

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:

12

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.

13

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.

14

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!

15

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.

16

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.

17

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?

18

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.

19

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.

20

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.