We have been chasing a random message send failure for several weeks on our latest batch of 3172 circuit boards. We have taken the following actions to try to resolve this issue. In the end, replacing a new 3172 with one from an older batch fixed the problem.
Add support for RAK latest firmware which is RAK RUI4.x
Start testing and test all points mentioned above and observe frequent msg send failure issue in some boards
Thought that might be issue in latest firmware. Downgrade firmware to RUI_3.4.11 (Firmware which we were using previously)
After Second test run 19 boards working fine. Start fixing 4 boards. Observe some noise in the DC line.
Start troubleshooting and add some capacitors and 1 out 4 boards start working.
Mark boards in two categories. 100% fine device not even a single msg send failure. 90% fine 1 out of 6 msg sent failed.
Now frequent msg send failure issue observed in 4 boards. At this point. Things getting complicated as frequent msg send failure issue observed in devices which were previously thought to be 100% fine.
After removing ceramic capacitors and replacing them with tantalum capacitors and it seemed fixed .
Replaced ceramic capacitors in all boards. After replacing, Tested all boards and frequent msg send failure issue again occurred in some boards.
Behavior was inconsistent, sometimes it worked and sometimes not.
Spent some more time with different test points but couldn’t find the root cause.
Replaced the RAK3172 module in our latest batch with one from an older working board.
The issue is identified.
Now my older board has a frequent msg send fail issue and the board which was showing frequent msg send fail issue started working 100% fine.
There must be some update/change to the RAK3172 module.
What (if anything) has changed on the more recent batch of 3172’s (on the right side of the pic)?
The older working 3172 shown is from our first batch of boards built perhaps 1 year ago. We have more recent batches where the 3172 looks identical to the faulty ones, and they work fine. Is there a batch # or other identifier on the 3172 label?
From hardware side there was no change since we started production.
The DevEUI printed on the label can tell us about the production date (in our internal databases).
I see on your newer boards you switched the ESP32 from the Wroom to another module without the PCB antenna. Can you verify that the problem is not related to the different ESP32 modules? What WiFi/BLE antenna are you using with the ESP32 module?
Do you use the same firmware version on both modules? Is it based on RUI3? If yes, what versions are you using?
Hi Bernd, thanks for the clarification re no hardware change. Firmware is the same - RUI 3.4.11. We switched from the ESP32-WROOM-32UE to the ESP32-WROOM-32D to simplify our antenna arrangement. We will investigate whether or not the change in ESP-32 model is causing this issue.
Actually (now that I have had a cup of coffee) the ESP32-WROOM-32D board on the left in the pic above failed the test with a newer 3172 with either RUI 3.4.11 or RUI 4.1 and passed the test with an older 3172 with RUI 3.4.11 (didn’t check 4.1 yet). No other change was made other than different 3172.
Can you share (by direct message) the schematics? I forwarded the problem to our R&D team and I am waiting for their reply.
Can you as well share the exact error message you are getting?
Are you using LoRaWAN or LoRa P2P?
I guess you are talking to the RAK3172 with AT commands. Can you give me the sequence of AT commands that you use to setup the device and then the AT commands used to send data.
Our LoRaWAN (not LoRa P2P) use case and testing is probably more vigorous than most. This test includes enabling 11 onboard relays at the same time and passes when a) all 11 relays are ON and b) 11 confirmations have been received. Previous batches of older boards passed this test, but our most recent batch all failed. We performed extensive testing on other aspects of our boards, then finally moved a 3172 from an old batch to one of the new boards, and it passed. We moved a new 3172 onto an older board and it failed. Something (perhaps a “same” component from a different supplier or whatever) seems to be different on our latest 3172’s as the problem moved with the new 3172and no other changes were made.
Still working on this. Need to confirm the 3172’s pictured above are actually the same. Both 3172’s pictured have an (I) on the label. In the store, (I) = EU868. In the store, 3172’s can be purchased with or without TCXO but I can’t notice any difference in the labeling when switching from with/without TCXO in the store. The labeling on the two 3172’s pictured above is quite different. Are they actually the same version/model of 3172?
(I) ==> version with IPEX antenna connector (N) ==> version without IPEX antenna connector
hardware is always the same
Modules sold for 8xxMHz LoRaWAN regions have a label with CE and UKCA certs, modules sold for 9xx MHz LoRaWAN regions have a label with FCC and IC certs
RAK3172 with TCXO have RAK3172-T on the label
Labels changed during lifetime as we got more and more certs and they didn’t fit anymore on one label.
Thanks for the clarification on labeling. Re Hardware is always the same, the thread below implies at least some substitutions/changes were made during the pandemic shortages. The ONLY thing exchanged between a working and non/working board was the 3172, and the problem moved from one board to the other. We will continue to investigate.
thanks for the clarification! This makes much more sense now.
Given that the datasheet mentions a TCXO, I guess this change was a result of the current shortages? Are there any plans to switch back to a TCXO in the future?
I’m asking because then you’d need a way to distinguish the crystal vs. TCXO module versions, either through different SKUs or some mechanism that would allow one to distinguish the different population options in software so that it can configure the HSE32 block accordingly.
There is a RAK3172 with XTAL and a RAK3172-T with TCXO.
They are sold separately and with different SKU’s.
They are marked on the label with the -T or without.
From outside you cannot differentiate the two, but they need different selection in the BSP if you are using custom firmware.
This should be a RAK3172-T but doesn’t have the label as you described.
Instead it has (TI) which is different from the (I) indicator on the non -T modules I have.
(I) ==> version with IPEX antenna connector (N) ==> version without IPEX antenna connector
In your store, the (I) appears in the pic beside the EU868 IPEX version. If I make no change other than to US915, the (I) disappears. The US915 with IPEX does not have an (I).
Re your response to Andrew’s comment, why would it matter where it was purchased? Are there fraudulent 3172’s being sold by others?
You asked Andrew, not me. We bought the ones in the picture at the top of this thread… 3172’s with IPEX (I), and no T, so no TCXO. The one on the left works fine, the one on the right does not. You didn’t answer my question. Why does it matter where it was purchased? I’m asking if 3172’s bought on Alibaba or elsewhere may not be real RAK products.
Berndt said “RAK3172 with TCXO have RAK3172-T on the label”
The image I sent was of modules purchased by my PCBA direct from RAKWireless per my specification which was: AU915, IPEX, TCXO. I even included the SKU.
As the boards are still in transit, I have no way to know whether the correct part was ordered and installed until I can test them.
My point was that the product labelling did NOT include “RAK31720-T”.
Instead, it included a “T” in the “(TI)” marking on the lower right.
As at this moment, I am assuming the part is correct until I can test and find otherwise.
It would be useful if there was a definitive document from RAK on part marking in order to help ensure part supply during production. Referencing a SKU that is not marked on the product really isn’t a great solution.
This order says STM32WL. Don’t see a SKU. The model currently specified in RAK store is STM32WLE5. Has there been any change in STM32 used in the 3172 since inception of the 3172?
