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.”
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.
