-
Posts
-
Hi All,
I received 2 Mini Ultra SAMD21 v3 boards and they are behaving very differently while running the same exact sketch.
First I had an issue with the Serial which I found out needs to be redifined as SerialUSB. So that’s solved.
The issue I am now seeing is that when I move one of the board around, the LED on Pin 13 will turn on/off or stay on and flicker continuously. The board is connected via USB to my Mac Book Pro Arduino IDE.This is happening on one of the board only and my code does not use the LED at all.
Any ideas what could be causing this?Amir,
It looks very likely your code is not uploaded onto the board? The behaviour suggested this possible cause. Can you load a simple Blink code? All IO pins are tested during production including the LED, so I doubt that is the issue.Also, make sure your DEVEUI is correctly loaded on the TTN dashboard.
I loaded the blink code and it’s fine. It blinks on/off
23:52:12.969 -> LED OFF.... 23:52:12.969 -> LED ON.... 23:52:12.969 -> LED OFF.... 23:52:12.969 -> LED ON....However I do get the following error very frequently and I have to push the reset button. It takes sometimes 2~3 attempts to load the code.
Sketch uses 11676 bytes (4%) of program storage space. Maximum is 262144 bytes. Forcing reset using 1200bps open/close on port /dev/cu.usbmodem14201Regarding the loraWan join, I am using an already defined DEVEUI which is already added to the Network Server (I am using loraserver.io). I know the code works, because the second Ultra Pro loaded with the same code is working perfectly.
Here is a partial log
23:57:56.957 -> HUB-001 STARTING... 23:57:56.957 -> LMIC: Initializing... 23:57:56.991 -> LMIC: Reseting... 23:57:56.991 -> LMIC: Starting OTAA... 23:57:56.991 -> [do_send] Get sensor data... 23:57:56.991 -> ============================ 23:57:56.991 -> T = -15 *C 23:57:56.991 -> H = 45 % 23:57:56.991 -> P = 1012 hPa 23:57:56.991 -> M = 75 % 23:57:56.991 -> G = -17 *C 23:57:56.991 -> L = 55245 lux 23:57:56.991 -> ============================ 23:57:56.991 -> [do_send] Packet queued 23:57:56.991 -> EV_JOINING 23:57:56.991 -> EV_TXSTARTDon’t pay attention to the data, they are bogus for now 🙂
And what seems to be happening is the Join request isn’t being received by the gateway at all.However I do get the following error very frequently and I have to push the reset button. It takes sometimes 2~3 attempts to load the code.
For more consistent uploading, double press the reset button in quick succession after pressing the upload button. The upload process is a bit inconsistent due to the timing and it happens with the SAMD21 bootloader unfortunately.
Is the DIO1 jumper at the back of the board shorted? We need that to be shorted so the LMIC can check the pin when it is waiting for a response. The radio was also tested (but without the DIO1 pin shorted) and verified working during production.
There are a host of other possible reason like boards are too near the gateway or antenna frequency mismatch.Are you able to enable further debugging on the LMIC section (must be enable from LMIC header file)? We might be able to see what is wrong there.
Is the DIO1 jumper at the back of the board shorted?
I haven’t shortened the jumper. The odd thing is again the second board working as expected and it’s not altered either.
I tested the boards with the same antenna and with only 1 device connected at a time. The gateway is about 12 meters away and separated by a ceiling.
As far as I can tell the join request isn’t being received by the gateway and the board is basically stuck waiting for a response. I’ll enable LMIC debug tomorrow (it’s late here) and report my findings.Take a look at the tutorial here. Although it is for TTN, the hardware setup is valid for any LoRaWAN server.
The code I am using is proven to work as expected and I already adapted it based on the tutorial. It’s working perfectly on one of the board.
But I added DEBUG to LMIC (also had to redefine Serial to SerialUSB in the config and it is throwing an Assert because the Radio went to sleep after sending the join request.
09:33:42.503 -> EV_JOINING 09:33:42.503 -> EV_TXSTART 09:33:42.538 -> FAILURE 09:33:42.538 -> /Users/anathoo/Documents/Arduino/libraries/MCCI_LoRaWAN_LMIC_library/src/lmic/radio.c:746static void startrx (u1_t rxmode) { ASSERT( (readReg(RegOpMode) & OPMODE_MASK) == OPMODE_SLEEP ); if(getSf(LMIC.rps) == FSK) { // FSK modem rxfsk(rxmode); } else { // LoRa modem rxlora(rxmode); } // the radio will go back to STANDBY mode as soon as the RX is finished // or timed out, and the corresponding IRQ will inform us about completion. }It’s failing here:
ASSERT( (readReg(RegOpMode) & OPMODE_MASK) == OPMODE_SLEEP );
This seems to confirm what you were saying about shorting the DIO1 jumper, correct?
But why this would only affect this one particular board and not the other?As a quick (and dirty) experiment, I commented out the ASSERT and the device eventually joined
09:44:58.149 -> [do_send] Packet queued 09:44:58.149 -> EV_JOINING 09:44:58.149 -> EV_TXSTART 09:44:58.892 -> EV_TXSTART 09:45:06.551 -> EV_TXSTART 09:45:08.216 -> EV_TXSTART 09:45:18.271 -> EV_TXSTART 09:45:25.227 -> EV_TXSTART 09:45:30.248 -> EV_JOINED 09:45:30.248 -> netid: 0 09:45:30.248 -> devaddr: 83FB40 09:45:30.248 -> appSessionKey: 651336BA162C8C845A17F578FACAF0 09:45:30.248 -> netSessiomKey: 54A84A2189EC1AFAA18E187547745994 09:45:30.248 -> sequence up: 0 09:45:30.248 -> sequence dn: 0 09:45:30.248 -> 09:45:30.248 -> EV_TXSTART 09:45:31.290 -> EV_TXCOMPLETE Done Sending data (includes waiting for RX windows)Note that the joine took a long time, so timing seems to affect the reliability of success when the DIO1 Jumper is opened.
Now here is a very basic question (I am not a hardware engineer). How do I short that DIO1? Do I just solder the pins together. Or maybe try to solder a jumper, so it’s configurable?
This seems to confirm what you were saying about shorting the DIO1 jumper, correct?
But why this would only affect this one particular board and not the other?The LMIC has always been using the DIO1 to check the state of the transceiver. As the pin is not shorted to DIO1, it could be floating.
Now here is a very basic question (I am not a hardware engineer). How do I short that DIO1? Do I just solder the pins together. Or maybe try to solder a jumper, so it’s configurable?
Please take a look at this image for shorting the connection. A blob of solder will short it easily.
Yes. That did it! After shorting the connections for both RST and DIO1 the board is now consistently joining successfully.
Well, really appreciate the help (and the patience) with this. I can safely say the boards have been validated to work as expected, except for that LED light staying on on one of them. But it doesn’t seem to affect any operations.I am now eager to update my LMIC sketch to use the low power mode. I’ll take a closer look at the tutorial for that.
Thanks again for that bit of hand holding 🙂No problem Amir, glad to help.
You should drive the LED to a known state else it would be floating. For low power, turn it off (active low).
That’s exactly what I am doing. It’s on when the radio is on to transmit and then off when in standby. That way I can also tell when data is being sent. I haven’t taken any measurement, but the sleep/wake cycle seems to be working as expected.
I am not using the LowPower library, though. Just using the RTC library like in the tutorial. I am not sure the standby API from the library is working the same way for the SAMD21.
I am not using the LowPower library, though. Just using the RTC library like in the tutorial. I am not sure the standby API from the library is working the same way for the SAMD21.
RTC library is enough. The LowPower library support was written by me prior before they implemented the sleep functionality to the RTC library.
- You must be logged in to reply to this topic.
