what type of enclosure do you use ?
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.
or take a laptop and some hot coffee outside 
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.
February 2017, emphasis mine:
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).
I tried powering the Uno from one of our outlets outside but the same behavior occurs.
can you show some console screenshots… especially where you can see how it joined (OTAA) and RSSI / SNR ? min distance 10 mtrs
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.
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.