I am using a Things Uno with a RAK831 gateway to build a weather station for my house. I discovered that my Uno does not like temperatures below 40F. I can leave it inside (75F) and have it run without any issues. But after 5 minutes outside around 40F, my gateway stops receiving messages from my Uno. If I bring it back inside, it start working again. I’d really appreciate any advice because Ive been trying to troubleshoot this for days to no success. Ive tried without the sensor (just send a fixed value), with different power supplies, different locations, different antenna placements and nothing has fixed it.
Here are some additional details about my setup
Gateway: RAK831+Raspberry Pi
Antenna: 6 dbm glass-fiber located outside (not the stock antenna)
Node: The Things Uno
Sensor: BME280
Power source: Anker battery
Activation method: ABP
That’s not extremely cold. Are you sure you get the Uno is continuing to loop through things? You might want to toggle an LED to make sure it’s not crashing or stuck in a rebooting loop. Maybe not stroking the watch dog in time due to it timing out faster, though I’d think it would tend to count slower at lower temperatures.
So here is a sample of tail -f /var/log/syslog when my Uno is INSIDE. No missing messages in the TTN console. Two messages were transmitted and detected as expected (Uno loops every minute).
2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: # RF packets sent to concentrator: 0 (0 bytes)
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: # TX errors: 0
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: ### [GPS] ###
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: # GPS sync is disabled
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: ##### END #####
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: INFO: [down] for server router.us.thethings.network PULL_ACK received in 103 ms
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: INFO: [down] for server router.us.thethings.network PULL_ACK received in 98 ms
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: INFO: [down] for server router.us.thethings.network PULL_ACK received in 95 ms
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: INFO: [down] for server router.us.thethings.network PULL_ACK received in 100 ms
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: INFO: [down] for server router.us.thethings.network PULL_ACK received in 98 ms
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: ##### 2019-02-03 02:50:56 GMT #####
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: ### [UPSTREAM] ###
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: # RF packets received by concentrator: 2
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: # CRC_OK: 50.00%, CRC_FAIL: 50.00%, NO_CRC: 0.00%
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: # RF packets forwarded: 1 (24 bytes)
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: # PUSH_DATA datagrams sent: 2 (419 bytes)
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: # PUSH_DATA acknowledged: 0.00%
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: ### [DOWNSTREAM] ###
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: # PULL_DATA sent: 5 (100.00% acknowledged)
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: # PULL_RESP(onse) datagrams received: 0 (0 bytes)
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: # RF packets sent to concentrator: 0 (0 bytes)
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: # TX errors: 0
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: ### [GPS] ###
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: # GPS sync is disabled
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: ##### END #####
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: INFO: [down] for server router.us.thethings.network PULL_ACK received in 100 ms
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: INFO: [down] for server router.us.thethings.network PULL_ACK received in 98 ms
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: INFO: [down] for server router.us.thethings.network PULL_ACK received in 100 ms
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: INFO: [down] for server router.us.thethings.network PULL_ACK received in 118 ms
Feb 2 21:51:22 B827EBFFFEAA9B5B ttn-gateway[331]: INFO: [down] for server router.us.thethings.network PULL_ACK received in 341 ms
Here is a sample of tail -f /var/log/syslog when my Uno is OUTSIDE. No messages in the TTN console.
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: # PULL_DATA sent: 5 (100.00% acknowledged)
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: # PULL_RESP(onse) datagrams received: 0 (0 bytes)
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: # RF packets sent to concentrator: 0 (0 bytes)
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: # TX errors: 0
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: ### [GPS] ###
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: # GPS sync is disabled
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: ##### END #####
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: INFO: [down] for server router.us.thethings.network PULL_ACK received in 101 ms
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: INFO: [down] for server router.us.thethings.network PULL_ACK received in 102 ms
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: INFO: [down] for server router.us.thethings.network PULL_ACK received in 100 ms
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: INFO: [down] for server router.us.thethings.network PULL_ACK received in 99 ms
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: INFO: [down] for server router.us.thethings.network PULL_ACK received in 106 ms
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: INFO: [down] for server router.us.thethings.network PULL_ACK received in 98 ms
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: ##### 2019-02-03 03:03:56 GMT #####
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: ### [UPSTREAM] ###
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: # RF packets received by concentrator: 0
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: # CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: # RF packets forwarded: 0 (0 bytes)
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: # PUSH_DATA datagrams sent: 1 (176 bytes)
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: # PUSH_DATA acknowledged: 0.00%
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: ### [DOWNSTREAM] ###
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: # PULL_DATA sent: 6 (100.00% acknowledged)
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: # PULL_RESP(onse) datagrams received: 0 (0 bytes)
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: # RF packets sent to concentrator: 0 (0 bytes)
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: # TX errors: 0
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: ### [GPS] ###
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: # GPS sync is disabled
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: ##### END #####
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: INFO: [down] for server router.us.thethings.network PULL_ACK received in 102 ms
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: INFO: [down] for server router.us.thethings.network PULL_ACK received in 101 ms
Feb 2 22:04:13 B827EBFFFEAA9B5B ttn-gateway[331]: INFO: [down] for server router.us.thethings.network PULL_ACK received in 100 ms
So I just noticed that occasionally this shows up in the logs when its outside.
Feb 2 22:12:56 B827EBFFFEAA9B5B ttn-gateway[331]: # RF packets received by concentrator: 1
Feb 2 22:12:56 B827EBFFFEAA9B5B ttn-gateway[331]: # CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%
Feb 2 22:12:56 B827EBFFFEAA9B5B ttn-gateway[331]: # RF packets forwarded: 0 (0 bytes)
Feb 2 22:12:56 B827EBFFFEAA9B5B ttn-gateway[331]: # PUSH_DATA datagrams sent: 1 (176 bytes)
Feb 2 22:12:56 B827EBFFFEAA9B5B ttn-gateway[331]: # PUSH_DATA acknowledged: 0.00%
Feb 2 22:12:56 B827EBFFFEAA9B5B ttn-gateway[331]: ### [DOWNSTREAM] ###
Feb 2 22:12:56 B827EBFFFEAA9B5B ttn-gateway[331]: # PULL_DATA sent: 6 (100.00% acknowledged)
Feb 2 22:12:56 B827EBFFFEAA9B5B ttn-gateway[331]: # PULL_RESP(onse) datagrams received: 0 (0 bytes)
Feb 2 22:12:56 B827EBFFFEAA9B5B ttn-gateway[331]: # RF packets sent to concentrator: 0 (0 bytes)
Feb 2 22:12:56 B827EBFFFEAA9B5B ttn-gateway[331]: # TX errors: 0
I see that crc error. I get those occasionally for no apparent reason. At least nothing of mine was transmitting, and gateways are pretty rare around me, so it could be the water meter or gas meter causing mine, but they don’t use LoRa modulation. Any chance your receiver is being overloaded? I take it that it works for a few minutes, then quits, right? When it does work, what kind of SNR or RSSI values are you seeing? It’s just not cold enough to create problems, imo. Oh, one other thing, you do have frame sequence number checks disabled, right?
So my current setup has the antenna maybe 20-30 feet away with direct line of sight. In that setup the SNR is 9.00 and RSSI is -39. I thought about my Uno being too close to the gateway so I moved the Uno to the other side of the house and the same behavior occurs. Also Im not sure if I have frame sequence number checks disabled. I’m new to TTN and LoRa (if you couldn’t tell haha).
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.”
