4. ATOM-DTU-NB-IoT - modem does not respond anymore

ATOM-DTU-NB-IoT - modem does not respond anymore

  • E

    Hi, I was playing with the DTU-NB some days ago until suddenly the modem stopped responding to any AT command.

    So I bought two new devices, and now none respond anymore.

    For testing I started to use "TinyGsmAutoBaud" (I also modified the code to use the correct PINs). With my first broken DTU - no response to any Baudrate.

    Since I seemed to broke the second module already and the TinyGsmAutoBaud also does not respond I simply put the Atom into my third unused DTU - which worked and got a response with 115200 - so the TinyGsmAutoBaud and Firmware seems to work.

    I tried the same Atom on my second (broken) DTU with no success. So I resumed playing with the third DTU, and pressed the rest button - and finally this one also does not respond.

    Is this a hardware issue? Any way to get the broken devices running again?

    Thanks for your time.

    0

  • Hello @erazor

    in my experiments with different modems (SIM7020, SIM7080, SIM7600 etc.) I found that some want a specific line ending to work reliably. I have the best result with \r only. \r\n\ kind of works and \n doesn't work for me.

    So, you could try to modify the TinyGsmAutoBaud code to only send an "AT\r" instead of the default "AT\r\n". See this line.

    Thanks
    Felix

    0
  • E

    Well, yes.... "AT\r" should be enough and this was even mentioned in the datasheets.

    Anyway, mostly people use tinyGSM and "AT\r\n" should work anyway.

    I tried "AT\r" - no difference, the modem remains silent. I also tried a USB-USART connection with 3.3V levels and tried different baudrates, spamming the modem with any combination of "AT\r\n" - no success.

    Normally it has autobaud, if not it should start with "RDY" - I'm not getting anything with powerup. The modems LEDs blink but thats all.

    I saw that they're translating the logic-levels from 3.3V to 1.8V. I'm not sure but these are looking completely strange to me.

    0_1676556849878_IMAG001.BMP

    There shouldn't be any 3.3V peaks, right? The image shows my TX line, somewhere at transistor Q3. NB_RX and U1_RX are looking quite similar, so maybe the transistor is broken?

    0

  • Hello @erazor

    I agree, I wouldn't expect 3.3 V peaks at the U1_RX side of the Q3. And yes, I guess the transistor could be broken, but it being broken in three devices - that is a bit hard to imagine.

    I never have used the TinyGsmAutoBaud code myself. I normally run all my modems with just 115200 and so far that worked just fine.

    Have you tried to measure what comes out of the modem, e.g. at transistor Q5? Maybe you can determine from that what baudrate the modem expects?

    Thanks
    Felix

    0
    E
     1 Reply
  • E

    @felmue there is nothing. I also removed and replaced Q3 with Q5. My idea was, that maybe Atom-RX line became output and killed Q3 but that's not the case.

    Removing the Q5 completely changed nothing.

    I ordered another two modules to check the signals but I start to think the issue is in the modem.

    Maybe I come to a point where I should ask the M5 team for help. This is kinda annoying, I really like the design of the DTU.

    0

  • Hello @erazor

    ok, I see. Yes, I think getting in touch with M5Stack support is probably best.

    Thanks
    Felix

    0
    E
     1 Reply
  • E

    @felmue thanks for your hints and your time!

    0
  • F
    Global Moderator

    Hi, can you offer me that code when the modem stopped responding? To see if my DTU will meets the same issue

    0
    E
     2 Replies
  • E

    Update for anybody who's reading this.

    My previous assumption that the reset-button kills the modem seems incorrect.

    I've had another two devices and carefully did not use the reset-button at all but these modules also stopped working.

    0
  • E

    @forairaaaaa you can find my code here:
    https://github.com/erazor83/nb_dtu_reset_issue/

    0