I try to change SF, BW and comunication baud rate to slower, but nothing workt at all in cold.

But I try to make my own FW for RN2483 with this http://ww1.microchip.com/downloads/en/DeviceDoc/40001864A.pdf . And now I have 9 modules in fridge (-30 °C) for 5 days and everything works fine. So I am pretty sure that there is a firmware issue. I use my own protocol instead of AT comands, I got more options to do. And as a bonus I have no consuption issue.I took me 2 days to make that work.

I did a 'fridge' and 'window' test.Can confirm that some RN2483 decides to stop transmitting when the temp gets below 10 degree C, and starts sending data back when gets warmer.Also, we quickly switched two outdoor deployed nodes from RN2483 batch 1633PTM to RN2483 batch 1621YHQ, and now they are transmitting data all the time. The software version is the same, so it must be a hardware issue.

Long time lurker here... I have exactly the same symptom as user "led" with various RN2483 chips (e.g. many of them are from the 1613GHM batch).

At about minus 10 to 11C the messages stop being received while the RN still reports "mac_tx_ok". Everything is OK again as soon as the temp rises above -10C. Microchip specifies -40 to +85C in their datasheet so I expect them to work on a fix asap. This is important for me as currently I plan to sell about a thousand outdoor nodes this year.

The last comment by wojciech makes me very curious and I would really appreciate any additional available info.

The applications are (much) more complex than just a temperature measurement, but I understand your point.

Well, there are a few arguments to stay with the RN (if Microchip gets this fixed): - there is a lot of time and effort invested in pcb design, application and library software development- the RN was one of the few (only) certified modules when we started looking at LoRa radios (about 2 years ago). I'm not really sure what the alternatives are at the moment.- the RN -at the time we needed to make a choice- was the only one available through the big electronic component distributors.- ease of use (through the AT-commands).

However, when this issue will not be resolved, a search for an alternative is indeed necessary. Do you have a suggestion?

there is a lot of time and effort invested in pcb design, application and library software development

nothing can go against this argument off course , but many customers are not satisfied at the moment.and what about 'mote/node sellers.. can you send your rn2483 based LoRaWAN hardware back because of faulty chips ?but probably there are also a lot of customers that use the chip indoors, or not at that low (minus 10) temperatures and they don't have a problem with the old batch.

So I contacted Microchip support and they informed me that:- by late march there will be a new firmware update that solves this problem.- the problem is not necessarily batch specific. Meaning, newer modules will probably also need the new firmware.

Affected users can contact their local sales representative via the so called NSCAR procedure and ask access to the new firmware, which is what I'll be doing next.

Update:So over the (almost) last two weeks I've called the local Microchip sales department and sent them an email, they would get back to me. I sent multiple emails to MicrochipDirect, they would get back to me.

The result: No mail, no call, nothing.

I noticed that none of the large distributors have any RN2483 chips in stock. Maybe they've been recalled or Microchip stopped selling them I don't know.

By now I'm really starting to worry whether I'll be able to deliver the applications that have been sold. And I'm very disappointed by Microchip's inactivity and non-communication.