If you go to the console page, click on applications, click on devices, click on that device and then click on settings. At the bottom of the page is a check box where you can disable frame sequence checks, make sure you set it to disabled. Since you are using ABP activation, the sequence numbers will start at zero when you power cycle the device. If sequence number checks are enabled, the network will think that a replay is occurring and will ignore the frames until the sequence number exceeds the number seen by the network so far. I’m pretty new at this too. -39 dBm seems a little low, but maybe not. Using a bsfrance lora32u4, I get stronger signals using the cheesy little circuit board antenna about 15’ from my gateway, indoors. I usually get about -30 for signal strength, sometimes as low as -39 depending on how I orient it. 10dB SNR sounds about right though. I was expecting a little more from your gain antenna, but it is further away and signal drops fast at first. It’s an inverse square kinda thing, so maybe -39 is about right after all. Like I said, I’m new at this too, but I’ve been tinkering with electronics and RF for a llong time. 40F isn’t terribly cold, -40F might be a little different though. Are you using the same antenna when you bring it indoors? If not, check the connectors and make sure that one has a pin and the other a socket for the pin. There are two kinds of SMA connectors, normal and reversed as well as male and female, so really there are four different connectors in SMA world. I don’t know why, I just know there is.
Edit:. After thinking about it, if it was a sequence number issue, the gateway logs in the pi would still show the frames being received. It doesn’t know anything about that, it’s the backend that does that.
inside that powerbank(?) are LiPo batteries, and they don’t like freezing temps, they tend to drop voltage hence your uno can’t transmit, the moment you bring it back to room temps it works again.
solution could be to use protection against cold, not only the uno but also your battery.
Does the code put out messages to the serial monitor ?
If so, I would put the node, including sensor and betteries in a plastic food box with a freezer pack and feed the serial monitor cable outside of the box. You can then sit in the warm and monitor what the node is doing.
In my workshop, I have access to some long USB extension cables, so I can sit at my Workbench, in the warm, monitoring and programming nodes that are outside.
Not sure to which firmware version the above applies, and if a fix was ever released. Also, the Kickstarter gateway was shipped in December 2017, but the Uno’s were shipped earlier, so I’ve no clue if those would have firmware that was released after February 2017.
The Things Uno is shipped with the old ‘defective’ firmware. Only if the user upgraded it to a newer version the bug may be fixed. Even then there will be issues with SF12 in the long term (hardware issue, that is why the rn2483a was released) so avoid using that.
So I actually sat outside with my laptop plugged into the Uno and watched the serial monitor. It showed the Uno was acting as expected (ie successfully transmitting every minute).
So it appears OTAA is not wanting to work while at room temp. This is what the console looks like. RSSI hovers between -70 through -80 and SNR between 9-11 Also the serial monitor from my Uno just loops and says “Sending: mac join otaa, Join not accepted: denied, Check your coverage, keys and backend status.”
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.
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.
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.
