Using the Waveshare Pico SIM7080G with MicroPython

[MrTinkerman]

Hi,

So I've been busy getting into LTE-M the past few days and dove in head first ordering a Waveshare Pico SIM7080G
The info I got came from the links below

First thing first, is this correct?

• The board basically has these connections: V+, GND, TX, RX and PWR_KEY to reset it.
• Communication to the module is done by sending AT commands over UART
• The board is designed for a Pico but any uc with UART and one IO should do right? (currently using a XIAO nrf52840)

I'm stuck at communicating over UART, the very basic first requirement, yay...
Maybe I broke the board by doing something stupid I'm not aware of, maybe it's faulty, maybe I'm doing something wrong.
At first I thought it was the UART (click for topic)

But looking at the TX/RX on the XIAO's side, the XIAO is sending data but the RX stays low while it should be high (see screenshot below).

My basic test code is posted below too.

Does anyone have any idea what's wrong here?

Thanks!

Additional info:

• I doublecheck my soldering connections
• I power both boards from a 10C 400mAh lipo
• I tested with and without m2m simcard
• I didn't power it without the antenna connected

The links:
How to build a cellular IoT device with the Raspberry Pi Pico — part one, the hardware
How to build a cellular IoT device with the Raspberry Pi Pico — part two, the code
korewireless/Super-Sim-Raspberry-Pi-Pico-Demos on github
Get Started with Super SIM SMS Commands and the Raspberry Pi Pico
Get Started with Data Comms and the Raspberry Pi Pico

Test code to communicate over UART:

import machine
from time import ticks_ms, sleep_ms

mdm = machine.UART(0, 115200)
pwr = machine.Pin(5, machine.Pin.OUT, machine.Pin.PULL_UP)
pwr.value(1)

'''
Info from SIM7080G_Hardware_Design_V1.05_230731.pdf

Page 26
The following methods can be used to power off SIM7080G.
Method 1: Power off SIM7080G by pulling the PWRKEY pin to ground.

Page 24
After the PWRKEY is pulled low, the module will be reset after 12.6 seconds
'''

def reset():															
                                                                        
    print('Resetting')													
                                                                        
    pwr.value(0)													
    sleep_ms(2000)   
    pwr.value(1)
        
    wait_time = 30				# Wait n seconds for the modem to become available
        
    s = ticks_ms()
    while ticks_ms() - s < wait_time*1000:
        print(f'Wait {wait_time - int((ticks_ms()-s)/1000)}')
        sleep_ms(1000)


reset()

cntr = 0

while cntr<250:				# From sstackoverflow.com/questions/64470980
                                                # The module also has auto baud rate detection, so you need to send AT a couple time to get the `OK' acknowledgement
    cntr += 1
    
    print(f'Sending AT cmd {cntr}')
    mdm.write(b'AT\r\n')
    sleep_ms(500)

    print(f'Serial data available: {mdm.any()}')
    
    if mdm.any():
        print(mdm.readline())

[peterhinch]

Are you sure you've connected TX on the host to RX on the modem and vice versa? A UART data line should never be stuck low: remaining in that state means something is broken. If you have the host RX connected to the modem RX, that would explain the stuck line.

Failing that check with a meter that the line isn't somehow strapped to gnd.

[MrTinkerman]

Thank you for clarifying, I will look into it tomorrow or over the weekend.

[peterhinch]

In general, on the UART of a board:
TX should be pulled high by the board itself and pulled low when transmitting
The RX should remain low, only to be pulled up but the TX of the board on the other side

As you state, the TX idles high and pulses low when transmitting.
The RX is high impedance. If you measure with a voltmeter between RX and Gnd it will read low. If you measure with a high impedance instrument like an oscilloscope, it may show an indeterminate level. The fact that it is high impedance means that, when connected to a TX, the wire behaves as per the TX.

A TX, disconnected from other equipment, that is stuck low has a hardware problem.

[MrTinkerman]

Thanks so much for explaining.

"A TX, disconnected from other equipment, that is stuck low has a hardware problem."

The TX on the Pico SIM7080 stays low no matter what, also if stand alone.

Conclusion, this board is a write off :(

[radu022003]

Hello, I have tried with the same board and the AT_TEST.py example and I could observe that the modem (SIM7080) was not sending anything back. When I connected a FT232 to the RX of the pico, I could observe that the communication was working as expected. My assumption is that the level shifter (TXB0104PWR) is not OK or it needs something changed (hardware).
Does someone has an idea what should be changed? I will also write an email to waveshare.

[MrTinkerman]

I'm not yet sure of what you have tried but I am interested in the outcome/reply from Waveshare.
I'd prefer to use the Waveshare board instead of the m5 stamp I'm currently using

[Pawelinode]

You have not defined RXD and TXD pins in machine.UART(0, 115200)
Are the default values correct?

[MrTinkerman]

Yes they are correct. Long story short, on the nrf52840, adding more parameters then uart and baubrate is not supported.
I am using a https://docs.m5stack.com/en/stamp/stamp_catm now and got it working without any issues.