Hello,
I’m new to TTN.
Registered FiPy device.
Using
lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.EU868)
app_eui = binascii.unhexlify('xxxxxxxxxxx')
app_key = binascii.unhexlify('xxxxxxxxxxxxxxx')
lora.join(activation=LoRa.OTAA, auth=(app_eui, app_key), timeout=0)
I can’t joint, only got activation messages with ““location_source”: “registry””
Can anybody help me please? What im doing wrong?
Thanks in advance
Just to check, did you get your Device EUI for the TTN setup?
Where does the location_source message appear?
Where in the world are you (town/city as well as country)?
Have you checked on the TTN home page that there is a gateway near to you?
Hello Nick,
My device EUI i got from
from network import LoRa
import ubinascii
lora = LoRa()
print("DevEUI: %s" % (ubinascii.hexlify(lora.mac()).decode('ascii')))
My message receveid, all like that
{
"time": "2020-07-01T16:07:48.463487418Z",
"frequency": 868.5,
"modulation": "LORA",
"data_rate": "SF7BW125",
"coding_rate": "4/5",
"gateways": [
{
"gtw_id": "eui-00023dfffe0f5945",
"timestamp": 3790330603,
"time": "2020-07-01T16:07:48.422961Z",
"channel": 2,
"rssi": -116,
"snr": -7
}
],
"latitude": 38.79921,
"longitude": -9.215544,
"altitude": 388,
"location_source": "registry"
}
I was about 100m on sunday from this gateway, not rssi problem.
Im in Portugal, city of Odivelas.
Yes, checked. One closer to me (890m sight-of-view) but funny i connect only to this one, 9.8km sight-of-view
And closer to one gateway on last sunday, in Lisbon, Portugal
{
"time": "2020-06-28T11:19:33.131886705Z",
"frequency": 868.5,
"modulation": "LORA",
"data_rate": "SF7BW125",
"coding_rate": "4/5",
"gateways": [
{
"gtw_id": "eui-00f142122877fc0d",
"timestamp": 3291423379,
"time": "2020-06-28T11:19:33.036896Z",
"channel": 2,
"rssi": -91,
"snr": 12
},
{
"gtw_id": "eui-00f142122877fc0d",
"timestamp": 3291423379,
"time": "2020-06-28T11:19:33.036896Z",
"antenna": 1,
"channel": 18,
"rssi": -87,
"snr": 15
}
],
"latitude": 38.756966,
"longitude": -9.115968,
"location_source": "registry"
}That’s the meta data that tells you about the transmission - the actual data your FiPy sent will be in the console above that block - it’s called payload.
Which means it did join and it has sent a message.
The "location_source": "registry" tells you that gateway location came from the TTN website, not GPS
the actual data your FiPy sent will be in the console above that block - it’s called payload
But i don’t have this on console, only activation messages.
Which means it did join and it has sent a message.
I guess not
Has_joined always return false
Right, so as you reveal more info, I can make better suggestions.
So, I’ve now learn’t that you have a good handle on most of this but we need to figure out why TTN is getting the join message but your FiPy is not getting a response or is not hearing it or is not processing it.
Just in case there is an issue with the Device EUI, can you switch the TTN setup to ABP and use the appropriate code to try that?
When one sees an Activation in the application/device’s Data page (orange icon), or sees the device’s “Status” change from “never seen” to some timestamp, then TTN accepted all of DevEUI, AppEUI and AppKey, and assigned a new DevAddr.
So, so far, so good! I’d say that the device did not receive the Join Accept.
Sure.
Tried but nothing on console, but program runs without problems
Thanks. And why don’t receive it, even when about 70m from antenna?
Messages are just broadcast, with ABP there won’t be feedback.
This does seem strange - @arjanvanb explains the network server is happy with the credentials but your device didn’t get the join accept.
But that should mean your ABP based message should have been heard and accepted …
I’m the first line guessing, hopefully @arjanvanb will bring words of wisdom shortly
For the ABP case see if there’s some way you can get a low level debug printout of the raw packet actually put on the air, then validate this yourself in the online LoRaWAN packet decoder. You’d particularly be looking for things like key mixups leading to MIC failure. If you keep restarting the node, you’ll also need frame counter checks disabled on the server.
For missing downlinks such as OTAA registration, prime suspects are always the node listening at the wrong time, and mixups about frequency and spreading factor.
I’d personally try to get ABP uplink working first, and I’d try to get my fingers down in the low level of the stack so I could see exactly what it was doing, and when.
If you really want to debug an ABP uplink over the air, and you can control the frequency and spreading factor used, then you can rig another node to listen continuously and summarize anything connected over a serial port - you don’t need to waste money on “fakeway” where someone has given a node its own embedded linux and plastic box, just use monitoring firmware on a cheap node that can go back to being a node when you are done with the test.
I really should get that tattoo’d on the back of my hands
Have you checked the lorawan API provided in Python for pycomm devices? Last time I checked the level of control over the stack was almost non existing. If it works you’re fine, when it doesn’t there isn’t a whole lot you can try…
I tried, program runs fine, but no messages receveid. I will try find someone with a gateway and watch debug messages on gateway
The above is key. Your ABP uplinks should be received just fine, just like the OTAA Join Request was received. Next, as apparently TTN discards the ABP uplinks, for ABP indeed the following applies:
So, temporarily disable the security. And check and re-check the DevAddr, AppSKey and NwkSKey in the ABP configuration in your device. I don’t know how you need to enter those details in the FiPy’s code (Hex, lsb or msb?), but as the secrets are easily changed anyway, please post a screenshot of TTN Console while in the ABP Settings page (everything below “Activation Method”, with the keys at least partially visible), and post the code that sets those 3 values, so others can validate.
Please post code as text, not as images.
So, while I agree that access to the gateway’s log would be great: if you don’t have such access then surely you should be able to get ABP working, as by seeing that OTAA Activation you know the device is in range of at least one gateway. And for OTAA: as the application’s Data page showed that Activation, you can be quite sure that TTN has commanded a gateway to send the Join Accept downlink. Seeing the gateway’s Traffic page in TTN Console won’t help much; you would need to peek into the actual gateway’s low level logs for more details. But that would assume the gateway is failing, while probably your device is at fault.
In fact, I’d revert to your first OTAA tests and take the device outside, hold it high, and move to a place where reception of the downlink might be better.
SOLVED.
Only increase SF on join.
Thanks to everyone.
