-
Posts
-
Hey,
I was just beginning to play with the new Mini Ultra LoRaWan and I had a few problems.
I was trying to use the Device Info example from TheThingsNetwork library, with a small adaptation in order to use the AltSoftSerial library.
As a result, the device seemed to be stucked when trying to get info from the RN2483. It seemed that I needed to reset the RN2483 in order to get it respond, until the next freeze.
After some research, I added a reset at the beginning of the sketch, but it didn’t perform much better.
I also tried lower speeds for the loraSerial, without success.I tested a direct serial connexion to the RN2483 using Hercules setup utility, which worked perfectly (got the hweui, etc.).
Eventually I tried to reflash the firmware of the RN2483 (bad idea) using Microchip’s java tool… but something went wrong and I bricked the chip. Seems that I’ll have to get a Pickit to reflash it.
Does this ‘freeze’ issue ring any bell to you? Did I missed something?
Thanx for the help!Below the tweaks I did at the beginning of the sketch:
#include <TheThingsNetwork.h>
#include <AltSoftSerial.h>AltSoftSerial altSerial;
#define loraSerial altSerial
#define debugSerial Serial#define freqPlan TTN_FP_EU868
TheThingsNetwork ttn(loraSerial, debugSerial, freqPlan);
void setup()
{
loraSerial.begin(57600);
debugSerial.begin(9600);
}
etc.Hi Marc,
Actually, there’s some slight modification to the TTN library example which I have posted here.All you need is to replace the correct appEui and appKey.
In order to communicate directly to the RN2483. Just load this simple code:
void setup() { pinMode(4, OUTPUT); // Pin 2 in connected to the TX of RN2483A used as interrupt during sleep pinMode(2, INPUT); // Let the internal pull-up on RN2483A does it job pinMode(4, INPUT); } void loop() { }Then slide the switch to “RN” position to talk directly to the RN2483A without the MCU. Pin 8 and 9 used for the AltSoftSerial will not interfere with the communication once the above sketch is loaded. This will be more reliable than the code you have posted.
I doubt the RN2883A is bricked yet. Try again with the Java tool and you could press the RN RESET switch as the software is a bit buggy to look for the RN2483A module, it does help.
Also, if powering from the 3.3V FTDI, make sure they are able to supply enough current. Most FTDI adapter out there (other than ours) only provide 50 mA of output current.
We upgraded the RN2483A firmware to 1.0.4 during production and also connected each unit to TTN during testing.
I’m sorry that you came into this issue as the user guide is not up yet. Will complete the remaining portion as soon as possible.
Thanks.Hi,
My mistake, I didn’t sneak enough on GitHub when I looked at the schematics.
I suspected that the soft serial lib could have issues with high bitrate, but I was somehow puzzled on how to achieve an auto-bitrate when reading the Microchip specs o)I will try using your script tonight + provide extra power, but I’m quite pessimistic: I had no issue talking directly with the RN2483 using the serial tool (+ switch in “RN” position) but I couldn’t get any data out of the RN after this silly FW update attempt. This is why I think this is beyond the buggy java interface. I also tried to reset the RN while the tool was probing the serial port, without success.
I’ll let you know
thanks for your help! 😉Hi Marc,
My mistake, I didn’t sneak enough on GitHub when I looked at the schematics.
I suspected that the soft serial lib could have issues with high bitrate, but I was somehow puzzled on how to achieve an auto-bitrate when reading the Microchip specs o)Probably my mistake for not updating the link from the product earlier. Added last week only. I’m very sorry on this.
I will try using your script tonight + provide extra power, but I’m quite pessimistic: I had no issue talking directly with the RN2483 using the serial tool (+ switch in “RN” position) but I couldn’t get any data out of the RN after this silly FW update attempt. This is why I think this is beyond the buggy java interface. I also tried to reset the RN while the tool was probing the serial port, without success.
Without that small sketch I gave, pin D8 and D9 will interfere with the RN2483A UART pins. I’m pretty sure it’s that. The Java program sometimes doesn’t response. At times, I also think I bricked some of the RN2483A, but after a few tries, it work.
I tried using your sketch and adding additional power, but I got the same behaviour: no discovery after several tries in the java utility, even with resetting the RN.
I tried also with a serial tool, at all speeds available: sometimes I get jibberish in return, sometimes nothing. It seems to be still alive but a little bit crazy 😉Hi Marc,
I think I know what happen based on a beta tester’s experience while trying to update the firmware. When you tried to update the firmware without uploading that simple sketch in the first place, the D8 and D9 will interfere with the updating process and causes the RN2483 to stuck in DFU mode due to corrupted data.
In order to recover it, once you loaded the simple sketch and flip the switch to “RN”, select “Bootloader Recovery” under the “Module” heading in the LoRaDevUtility, that should help to update the unit’s firmware properly.
by the way, with pin 4 set to HIGH, what are the risks to short the pin with the RN RST button?
Yes, you are right, spot on there. I will probably add a diode to protect in the next revision and will add a note somewhere. Thank you for pointing this out.
Just load this simple code:
hi
I tried to upload your simple program to read out the Device-ID with AT-Commands using a terminal program (sys get hweui).
I was not successful to upload it with different boards selected in the arduino-ide (Genuino UNO, TheThings UNO)
I also used differnt FTDI-adapters.Could you please enhance your documentation and give us an example to read out the device-id in case all your customers need that for continuing with TTN
Thanks.
I tried to upload your simple program to read out the Device-ID with AT-Commands using a terminal program (sys get hweui).
I was not successful to upload it with different boards selected in the arduino-ide (Genuino UNO, TheThings UNO)
I also used differnt FTDI-adapters.Board should be Arduino Pro Mini ATMega328P 8 MHz 3.3V.
Did you flip the slide switch to RN after uploading the simple code? Also, most FTDI adapter comes with 3.3V that has only 50 mA (ours come with 200 mA). Baud rate should be 57600 bps when communicating directly with the RN2483.
And if you upload the example code posted on our repository, that itself will print out the DEVEUI on startup. You don’t have to deal with the RN2483A.
Could you please enhance your documentation and give us an example to read out the device-id in case all your customers need that for continuing with TTN
Yes, I will complete the documentation by this weekend.
Board should be Arduino Pro Mini ATMega328P 8 MHz 3.3V.
Thanks for your fast answer.
With that board I could upload your MiniUltraLoRaWANSendOTAA successfully!Did you flip the slide switch to RN after uploading the simple code
As I wrote I could not upload your Simple program and that’s also no longer needed.
The other one did print out the Device-ID at –STATUSThanks for your fast help
Urs
- You must be logged in to reply to this topic.
