Hi, I’m using a RAK4631 device with FW 18.104.22.168 (battery, supported by solarpanel) and see some power problems. The device stops working, when exchanging the 16850 battery I see still 60% capacity, should be enough for some more hours/days. Is there any bug in the FW known, that could cause an early shut down of the device? Is there a fix available?
Already fixed in the upcoming 2.0.8.
May you provide more details about your solar hardware setup?
Thanks, when can I expect the 2.0.8 to be released?
I use the following solarpanel from ALLPOWERS, 2.5W 5V / 500mAh, size 130x150mm. Snow and icy rain doesn’t seem to be compatible with the panel :-), but this is expected. Nevertheless, even on a cloudy day as today, I see stable battery levels (see screenshot attached).
I don’t have information about the release. But you may use this firmware, It already includes all fixes related to power management for RAK4631.
firmware-rak4631-2.0.8.aa19718.uf2 (1.0 MB)
Also, may you share the script for generating this fancy table?
Thanks for the heads up on the FW 2.0.8, that’s great.
Concerning the battery levels: I used the iOS app, where you can see “Device Metrics Log”, there is a save function, when I opened the correponding file with Numbers, I get the table. This is a very nice feature to check, if the power management and the particular setup works fine.
I updated the device with the FW 2.0.8, worked for 18 hours, but now, the device is again in sleep mode, or crashed. I attached two screenshots.
First one shows, that this morning the battery level was still 91%, so no condition to shut down the device. I think it is not a problem of power supply.
Second one shows the entry in the iOS app, that the device was last heard 4 days ago, but the device metrics log shows entries from this morning, so somehow, these information do not fit with each other.
Do you have any idea, what I can do to get this device running reliably? Thanks for your help.
Official 2.08 just released a little bit ago. You might try that next in case there’s other changes that weren’t included in @D4rk4 's build.
I updated the device with the released FW 2.0.8 alpha and I’m looking forward to check, if the problem is solved.
Interestingly, even so, the device was not visible in the LORA network, I was able to connect to the device via BT without any problem. So it seems that the device didn’t crash completely, but just stopped the LORA service or went into sleep mode. Maybe this information can help to identify the problem.
For the update of the FW is used the “nRF Connect” App and teh OTA package, worked fine.
It might be that you then reached the regional duty cycle limit. With EU_868, if the ‘AirUtilTx’ value which you can check when running
meshtastic --info is higher than 10% on average for an hour long, you will hit it. You will also be able to check that with the iOS app version 2.0.8 which will be released soon, or by checking the serial log. If you try to send something when it seems to have ‘stopped the LoRa service’, it will show that you hit the duty cycle limit if that really is the case.
You will hit it if you send a lot of messages, which might be either text, position, environmental telemetry etc. The duty cycle limit can be overriden, but then you will violate the regulations if you are not a licensed operator.
The AirTm was always below 10% and in the last 10 days below 3%, so that might not be the problem (information taken from the device metrics log). Also, until the network isn’t stable to don’t use it very much, so the message traffic is nearly zero.
Strange, after the update, device worked for 5 minutes and stopped working thereafter for about 1 hour. Without any interaction, it showed up again now and seems to work.
@D4rk4 Hi, I have seen that the beta 2.0.8 is now available. Do you think that this firmware will fix the problems that I see with my RAK 4631?
My solar node based on RAK4631 is working without any issues about 2w on this firmware.
Second “QA” node working on the release firmware 2.0.8 also without any issues with the ROUTER_CLIENT role.
Don’t use the ROUTER role for solar RAKs for now. It’s not fully tested, and I still got shutdowns on 2.0.8 on the QA node in the ROUTER role.
That’s interesting. I mentioned, that I have the ROUTER settings 3-4 weeks ago. When updating the firmware is used “Meshtastic_nRF52_factory_erase.uf2” to erase the setting to have a clean start. I connected the RAK with my MAC and moved this file to the folder. When starting with the node after FW update, I realised that some of the previously changed settings were still changed and not back to default mode.
So, since you mentioned, that you also have some problems with the ROUTER mode, could the problem be, that the ERASE method for the RAKs is not working well somehow?
It’s just related to power management behavior in ROUTER mode, it’s not related to stored settings.
But I also realized, that the HOP Limit settings weren’t erased by using the “Meshtastic_nRF52_factory_erase.uf2” file. Isn’t this the job of this step in getting a clean new installation? Is there another way, to clean the device before installing the latest 2.0.8 beta?
@D4rk4 I upgraded the RAK to the latest released firmware “firmware-rak4631-2.0.8.090e166.uf2”, since 24 hours the device is running well. But I observed, that the device seems to have problems keeping the time and date information. Please check the attached device metrics log: battery is around 95%, but yesterday afternoon the device lost time information, but continues to work somehow. Could this behavior be part of the problem, that at some point the RAK is loosing connection to the LORA network?
I made some more observations, which might help to find the bug in the RAK 4631 Firmware:
The device stopped again participating in the LORA network, and previously I observed, that the device can still be reached via BT. So the device didn’t stop at all, only parts of the functions stopped.
At the moment, the device is in the list with the remark “Unknown Age” (see screenshot).
But I realized, that the device metrics are still updated. So the device is still communicating with the other devices through the network, but it doesn’t participate in the mesh to enable to reach remote devices, as it is possible, when the device is resetted.
Please see the two screenshots of the device metrics log attached.
I guess, that the device somehow lost the GPS signal (maybe part of the settings in the firmware, that GSP updates are stopped after 24 hours), without the time from the GPS signal, some functions of the devices (mesh participation) seems to stop. But other functions (metrics update) are still working.
I hope, that this description will help to identify the problem, and that the problem can be fixed in the next FW update.
Do you see duty cycle errors in the mesh log?
@garth I checked the mesh log, it only shows data from today, but I wasn’t able to find errors in this document. I attached the document, maybe it can inform you about the reasons for the observed issue. Thanks for the help, I’m really struggling getting the system to work reliably.
maybe you can just get another device ,
best would be 19007 or 19003 base board.
i was having problems more or less similar to the ones you described, but just on one set of hardware with older 5005-0 board…
other Rak-sets work fine…