Can you post a copy of your global.conf.json file? Those console messages seem a bit odd for US, I think.
Edit:. Actually, it would be the node choosing those spreading factors. I haven’t tried OTAA yet. The backend doesn’t seem to be sending any response, so I’m guessing that the message is just saying that it didn’t get any response. Are those console messages from the gateway page, or the application or debit page?
Given the headers/columns, this is the gateway’s Traffic page.
For some gateways (or: packet forwarders?) the gateway’s Traffic page does not show the orange Join Request items (but only the green Join Accept messages, if the gateway was selected to transmit that). Or maybe the orange Join Requests are only shown in the gateway traffic when not accepted?
@dhclark18 did you click those Join Request items to check for more details?
When looking at the application/device’s Data page, the orange Join Requests should also show the assigned DevAddr.
That image was from the gateway page.
It shows the Dev EUI for each request. I missed it when I took the screenshot.
Shouldn’t it show some kind of downlink on the console gateways page if it saw a join request?
Yes, if the Join Request was accepted. So: if the packet was not somehow mangled, which would make the MIC fail, and if the node is configured with the correct DevEUI, AppEUI and AppKey and used a unique DevNonce for LoRaWAN 1.0.x.
If multiple gateways received the Join Request (orange icon, possibly not shown in the gateway’s Traffic page, but surely shown in the application/device’s Data page, if accepted), then only one of those gateways will show the Join Accept (green icon) in TTN Console.
Clicking an item to expand it, should show much more! Make sure there is no error, such as OTAA shows "Activation DevNonce not valid: already used" or Activation not valid - no gateways available.
This is all I see when I click to expand:
{
"gw_id": "removed by me",
"payload": "AEhxAdB+1bNwQVQbAAujBABsSSO4byg=",
"dev_eui": "removed by me",
"lora": {
"spreading_factor": 10,
"bandwidth": 125,
"air_time": 370688000
},
"coding_rate": "4/5",
"timestamp": "2019-02-03T15:40:55.991Z",
"rssi": -72,
"snr": 10.8,
"app_eui": "removed by me",
"frequency": 904700000
}
I’m lost:
It seems the problem changed? Are you sure the configuration is still the same? (So: are you sure DevEUI, AppEUI and AppKey have not changed since things were working, unless being put into the cold?)
Ah sorry I forgot to clarify. My project uses ABP (OTAA hasn’t worked for me for whatever reason). BoRRoZ asked for screenshots of my device running in OTAA mode so I switched it to OTAA temporarily. Also, I updated my RN2903 to firmware 1.0.3 since it was hinted that this behavior is caused by a firmware issue. Its currently 60F so I will just wait until tonight to see if the new firmware fixed the issue.
So just to clarify for all who are reading. Since my first post where I outline my setup, the only things that have changed are the location of the Uno (on our side porch without line of sight of the antenna), the outdoor temp (now 60F), and the firmware of the RN2903 (from 0.9.5 to 1.0.3). Under these conditions, the Uno is working just fine.
So after a few days in below 40F, it no longer stops transmitting when cold. It appears the new RN2903 firmware has fixed the issue. Thank you everyone for your help!
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.