Using the Waveshare Pico SIM7080G with MicroPython #14356

MrTinkerman · 2024-04-22T19:29:57Z

MrTinkerman
Apr 22, 2024

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 · 2024-04-23T16:30:51Z

peterhinch
Apr 23, 2024
Collaborator

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.

12 replies

MrTinkerman Apr 24, 2024
Author

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

peterhinch Apr 25, 2024
Collaborator

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 Apr 25, 2024
Author

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 Apr 27, 2024

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 May 1, 2024
Author

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 · 2024-05-01T17:01:44Z

Pawelinode
May 1, 2024

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

1 reply

MrTinkerman May 1, 2024
Author

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.

CrabbyPete · 2025-05-05T11:55:17Z

CrabbyPete
May 5, 2025

I am curious, did you ever get this to work?

1 reply

MrTinkerman May 17, 2025
Author

No, I switched to the m5stack module and the waveshare module has been collecting dust since then.

CrabbyPete · 2025-05-17T12:35:25Z

CrabbyPete
May 17, 2025

Are you using the same code?

0 replies

MicroPython

Using the Waveshare Pico SIM7080G with MicroPython #14356

Uh oh!

Uh oh!

MrTinkerman Apr 22, 2024

Replies: 4 comments · 14 replies

Uh oh!

Uh oh!

peterhinch Apr 23, 2024 Collaborator

Uh oh!

MrTinkerman Apr 24, 2024 Author

Uh oh!

peterhinch Apr 25, 2024 Collaborator

Uh oh!

MrTinkerman Apr 25, 2024 Author

Uh oh!

radu022003 Apr 27, 2024

Uh oh!

MrTinkerman May 1, 2024 Author

Uh oh!

Pawelinode May 1, 2024

Uh oh!

MrTinkerman May 1, 2024 Author

Uh oh!

CrabbyPete May 5, 2025

Uh oh!

MrTinkerman May 17, 2025 Author

Uh oh!

CrabbyPete May 17, 2025

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

MrTinkerman
Apr 22, 2024

Replies: 4 comments 14 replies

peterhinch
Apr 23, 2024
Collaborator

MrTinkerman Apr 24, 2024
Author

peterhinch Apr 25, 2024
Collaborator

MrTinkerman Apr 25, 2024
Author

MrTinkerman May 1, 2024
Author

Pawelinode
May 1, 2024

MrTinkerman May 1, 2024
Author

CrabbyPete
May 5, 2025

MrTinkerman May 17, 2025
Author

CrabbyPete
May 17, 2025