Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • #13410

    Amir Nathoo
    Participant

    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?

    #13412

    LIM PHANG MOH
    Keymaster

    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.

    #13414

    Amir Nathoo
    Participant

    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.usbmodem14201

    Regarding 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_TXSTART
    

    Don’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.

    • This reply was modified 1 week, 4 days ago by  Amir Nathoo.
    #13417

    LIM PHANG MOH
    Keymaster

    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.

    #13419

    Amir Nathoo
    Participant

    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.

    #13421

    LIM PHANG MOH
    Keymaster

    Take a look at the tutorial here. Although it is for TTN, the hardware setup is valid for any LoRaWAN server.

    #13427

    Amir Nathoo
    Participant

    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:746
    
    static 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?

    • This reply was modified 1 week, 4 days ago by  Amir Nathoo.
    #13430

    Amir Nathoo
    Participant

    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?

    #13432

    LIM PHANG MOH
    Keymaster

    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.

    #13434

    Amir Nathoo
    Participant

    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 🙂

    #13436

    LIM PHANG MOH
    Keymaster

    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).

    #13447

    Amir Nathoo
    Participant

    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.

    #13456

    LIM PHANG MOH
    Keymaster

    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.

Viewing 13 posts - 1 through 13 (of 13 total)

You must be logged in to reply to this topic.