Forum Replies Created
-
Posts
-
Hi Andrew,
Did you received my email few days ago?
I can get the MiniUltraPro to do a soft reset with the command: NVIC_SystemReset();
Yes, you could do that. But, you would need to redo the rejoin network process.
I think you previously mentioned that 1.0.5 doesn’t work with the MULWAN.
I mentioned not working well generally as mentioned over here.
With the Sodaq firmware updater on Github (https://github.com/SodaqMoja/RN2483FirmwareUpdater) is a ,h file (HexFileImage2903AU_097rc7.h) but the hex definition is embedded in the C++ .h file. Do I need to strip out these C++ lines to produce pure hex before attempting to upload to the RN2903?
I went through the code over there. I believe what it does is, instead of using the Microchip utility to upgrade the firmware of the RN2903/RN2483, they load a special code that store the new RN2903 firmware onto the main MCU (on Sodaq, it is the ATSAMD21G18 which has 256 kB of flash, plenty!). This probably because they weren’t able to do it reliably directly from PC to RN2903 or for whatever reason limited by their design. And one more thing, this whole repository code won’t compile for an AVR-8 MCU as it can’t fit the entire code.
They converted the RN2903 .HEX file into a .h that contains special AU915 firmware (I believe this is not official and Sodaq themselves are big customer of Microchip, hence probably they have a copy of it). We could extract this and reformatted it into a regular .HEX file. But, to be safe, I would recommend asking them for an original copy. Then, we use the Microchip utility to update. I used the software many times and even in the case it lock up, it has a recovery mode that works well.
So, back to the 1.0.5 or even 1.0.4, I believe that won’t solve your issue as you are running AU915 band which is not officially release under these official 1.0.4 and 1.0.5 release.
I have been updating the RN2483A that was previously on 1.0.3 as the 1.0.4 was publicly available faster than the RN2903A’s. I have no issue updating them using the Microchip tool for a big batch of the modules. With Mini Ultra LoRaWAN, we are not using the ATMega328 MCU in between the PC and RN2903A, it is direct connection. Those who have issue are due to using SoftwareSerial or having the MCU acting as a bridge.
After reading your review on the uGateway’s product page, I noticed you are running Australia AU915 and not North America’s US915. Although they are similar, but there are differences. Unless on 1.0.4 has some patch that takes care of this, I’m pretty sure it won’t work.
Also from the debug messages of your Sodaq unit, it stated the unit as having a RN2903AU module (only RN2903A exist). It means it is clearly having an AU915 firmware which is not released to public before and the firmware revision is stated as 0.9.7rc7. It means it is still a release candidate. So it is not a 1.0.4 as you have mentioned earlier.So, I guess we can maybe try the 1.0.4 (or the Australian 0.9.7rc7 that you have access to). Please reread this message on the firmware upgrade.
The output suggest nothing is wrong on the device side. Both the TTN dashboard setting also tallies with the one on the node.
I can see you are using the USB adapter to power the board. Can you try powering the board by supplying maybe 2xAA to the VBAT pin? And de-solder the solder blob underneath the CH340E USB-Serial adapter so no power is being supplied from the adapter to the Mini Ultra LoRaWAN. Sometimes, the USB port output current is not enough especially from side port of computer or older motherboards.
Also, do you have access to the debugging messages on the gateway as well? You should be able to see any LoRa packages even if the TTN setting is incorrect. Also, make sure the device and the gateway distance is not too near each other if they are in the same room.
The gateway you are using is not a single channel gateway right? And if it is a typical 8 channel gateway, just make sure the uplink channel tallies with the ones shown by your device debug messages as above (channel 8-15).
Then only, we try the 1.0.4 as a last resort although I doubt this is the issue.
What is the output from the debug serial?
I have customer getting this work on 1.0.3 straight out of the box on US frequency on TTN. Let’s check the debug serial output before making a decision on the upgrade. All I know is, 1.0.4 is okay but the newer 1.0.5 has issue to work properly on TTN.
To upgrade on the Mini Ultra LoRaWAN is simpler, follow the instruction here. Then you could use the Microchip upgrade tool to upgrade the RN2903A firmware to 1.0.4.
Please provide a screenshot of the TTN dashboard setup of the device and the AppEui added in your unit code. You can blur the private and confidential field.
Also as the RN2903 only supports US band officially, are you using a US915 gateway in Australia?
If you load the example code here (which you must also add your own AppEui), the debug messages on the serial at 115200 bps will print out the DevEui.
Reflow Oven Build by Tom Jenkins. 3D printed casing was printed on a CR-10 3D printed with a 0.2 layer height using PETG. 3D print files for the casing available here!
Uses the Tiny Reflow Controller V2.
Parts and components used:
The SLEEP_1S uses the WDT as a timer to wake up. When used as timer, the WDT cannot be used to reset the MCU when it hangs. The only way to do this is to SLEEP_FOREVER but uses other mechanism to wake up (example: external RTC) and but uses the WDT to reset instead.
Looking back at your initial question, so this issue also occurs when you used the RadioHead library. The 2 main things that are common here is the sensor that you are using. Have you done a burn in test with these sensor to verify the library is reliable?
And regarding the frame counter as seen on the TTN backend, are these number increasing (unless you manually hand reset them)?
May I know what environment these devices are deployed? I asked this because I have a customer in Indonesia that initially tested some devices and are able to achieve some commendable in urban area. But, once they move into pretty flat palm oil plantation, everything fails. They weren’t able to figure out what went wrong until they came back to me. As I have experience in deploying in such environment, the moment they mention palm oil plantation, I told them it’s the water inside the tree trunk that is attenuating the all the signal. So, let me know some details because sometimes you might overlook things.
I am trying to do this but struggling with the library. When I try to make a file and write a char to it within the TTN code, it seems not to be registering anything. in any case, I am still at a loss on how to actually get intelligent error messages from this. I can probably just write an indicator after each part of the script to know where it stopped, but is that what you are suggesting? A simple example would be really nice.
Drop me a mail on this part, let me check if I can chop out some code from some existing data logging and tracking project.
Next to the 15 mini ultra pro v3’s, I now also ordered the Mini Ultra LoraWAN. I am going to set this up as well to see if it brings me any further.
You do know that the Mini Ultra LoRaWAN’s RN2903 has yet to support AS923 band?
If the Q&A on this forum does not resolve the issue, can we look into a bit of a closer discussion or consultancy to solve it?
I’ll try to help as much as possible but you must have notice my reply came in quite late in the day although we are in the same time zone as I takes care of my kid during the day and work at night and weekend.
I am not sure how the duty cycle violation will affect the functionality: could it mean that the microcontroller stops sending altogether? I have followed your code which, I thought, handles duty cycle violation?
The LMIC core will check it’s timer to see when it was last sent. This will cause the packet to be queued instead. The duty cycle handling when entering sleep was missing unfortunately. I did file a request to patch this but it was never being done. You can see one of the comment on resetting the duty cycle although it is not a right way to do it. But as long as you adhere to the duty cycle rules, then it should be okay.
Also, from the TTN backend, does the frame counter went missing or jumps?
How should I ensure all error messages go to serialflash? Is it a matter of simply redefining Serial to SerialFlash? I guess I need to take care of the sleep cycle of the SerialFlash as well?
You need to call the SerialFlash write function to write data into it. You can do this but placing them at strategic places like when a EV_TXCOMPLETE takes place, or when you are reading the sensors. Then you could load a simple read from file firmware when you want to analyze them.
If this is caused by a hardware problem, say some moisture intrusion, would it have this kind of behavior (where it stops but then after reset works again for hours or days with 4 pressure sensors)? In that case, would I get anything from messages?
As someone that deploys WSN in harsh environment in the past, in my opinion, if a bug behavior is consistent across all devices and can be quantified, it is usually a hardware issue. But, if it random, it is most likely a firmware issue.
Hi Thomas,
Are you taking care of the duty cycle violation due to the sleep and LMIC timer not running during sleep?
One of our customer has been running the MCCI branch of the LMIC on AS923 in Indonesia for many months without issue with the duty cycle aspect taken care of. If the duty cycle is violated, your packet will not be sent.I would suggest using the on-board serial flash as an error logger if you are not using the USB. That at least you will be able to know when and what happen.
A workaround is to use the ArduinoLowPower library. The rising and falling edge interrupt will only work with that library as the clocking to these peripheral are patched within that library itself.
