Circuitpython example with the Lora E5 Chassis

[KenSamson]

This is not truly an issue with this repository, though it is a request to be able to submit Circuitpython code as an example for others to see, along side of your other examples.

I have an example that I would very much like to submit to your collection:

On the WIO terminal, I'm trying to define the two pins for the UART so I can receive information from the GPS on the LoraWan module also sold on SEEED's website.

So to be clear, I have one of these:

https://www.seeedstudio.com/Wio-Terminal-p-4509.html

plugged into one of these:

https://www.seeedstudio.com/Wio-Terminal-Chassis-LoRa-E5-and-GNSS-p-5053.html

To talk with the E5 Lora module, it's very simple in circuitpython... you define a UART like this:

uart = busio.UART(board.RX, board.TX, baudrate=9600)

And then you can send and receive to that uart.. and it works great! I have code that does this, and can put those messages onto the screen of the Wio terminal.

Now, for the GPS:

I have no idea of how to define the two pins for the GPS hardware connection. Looking at the source code for this project:
https://www.seeedstudio.com/WioField-Tester-Kit-p-5282.html (from github)

So I look at that code, I check out the schematic for the Lora chassis, I check out the schematic fo the WIO Terminal... and nothing seems to match up.

I have tried every combination of pins in circuitpython that are even remotely possible to see if I can find the GPS, but nothing seems to work!

I've posted on the forum.. I've posted on the Discord server.

I'm not asking anyone to write my code for rme... just help me with the uart statement to be able to talk with the GPS module.

I've been working on this for well over a month, and I do not seem to be getting anywhere with it.

Ken

I was trying here to define microcontroller pins to see if I could see any of the GPS output sentences... but I have not yet been successful.

import time
import board
import busio
import microcontroller
uart = busio.UART(microcontroller.pin.PB02, microcontroller.pin.PB00, baudrate=9600)
uart.write(output1)
time.sleep(.5)
print(uart.readline())
time.sleep(.5)
print(uart.readline())

[t-ikegami]

Short answer will be: not possible without hassle.

CircuitPython does not support software UART (yet), so that UART communication with D2/D3 pins is not possible. As I don't own the chassis (jealous!), the following stopgap measures are not tested; I just guess from schematics.

1. Detach and wire (for testing purpose)
   Detach the chassis from Wio Terminal, connect GPS UART pins to Wio Terminal TXD/RXD pins (as well as 5V, 3V3, and GND), and try busio.UART.

2. Use I2C
   board.I2C() is connected to GPS (address 0x10). Information available seems to be dependent on the firmware. It worth to try anyway, I think.

3. Hack the chassis
   If UART is really necessary, open the chassis, rewire the GPS UART connections (15/17) to, say, PB00/PB02 (20/22), and your code　should work.

Hope this helps.

[KenSamson]

These are good ideas... I2C may be easy to try.

Mapping to other pins is probably a bit harder.... but I could pull the case open to see..

I'm still not sure how to map the pins to define for the i2c, but I will see if I can tell tomorrow.

Would you like me to get a lora chassis and send it to you?

[KenSamson]

Ok... I pulled the cover off.. the board actually looks pretty well made.

The "standard" pi 40 pin connector staring at my face made me realize that I could breadboard this thing, move the pins to where I want them on the breadboard, get the code working on the new pins with a UART defined on other pins.

I can then ensure that those pins in this chassis are not connected, and then just install jumpers on the connector pads.. which are a lot easier to do than doing anything more serious in terms of re-routing the board. It would also mean if anyone was using other code written for this board, it would still work as I would not disconnect those pins either.

The downside with this approach is that a standard code repository is not going to function without this mod.

Given that.. I'll still try to find the time to try the I2C approach... I could see if those pins map through to the processor while I have it open. That really would be the most portable approach, to use the hardware as it is. I don't mind putting a jumper on, but not everyone is going to want to do that.

Can you tell me where you saw the I2C address published? (Please?) I've not been able to find that detail.

---

When I define the I2C using microcontroller.pin.PA16 and PA17, I get the error that no pull up is found.
So it looks like I will have to breadboard this as well, add the pullups and then see if it wants to talk. Breadboard is required for either trying to map UART to different pins, or to get the I2C to work. Still.. this is good progress. I do not mind working hard... I will get this to work eventually. There is no reason with good code and/ or soldering that I can't talk to this module.

[t-ikegami]

I thought that I2C can be used just as-is. Then I re-checked the schematics, and found that the pull-up registers are NC! Possible workarounds are:

1. Connect I2C device with pull-up registers
   For example, connect
   https://www.seeedstudio.com/Grove-AHT20-I2C-Industrial-grade-temperature-and-humidity-sensor-p-4497.html
   on the left grove port of Wio Terminal, and I2C should work.

2. Enable pull-up of the chassis
   I guess that there are patterns on the PCB for R71 and R72. Put 10k registers there.
   If you put close-up photos of the PCB, I may check whether this is viable.

For the I2C address, I checked Quectel L76-LB GNSS datasheet on
https://www.seeedstudio.com/Wio-Terminal-Chassis-LoRa-E5-and-GNSS-p-5053.html
Anyway, if I2C is enabled, you can check available addresses by

import board
i2c = board.I2C()
i2c.scan()

Convenient, yah?

Would you like me to get a lora chassis and send it to you?

If you are living in the next door :-) Otherwise, the shipping cost is ridiculous.

[KenSamson]

So I brought the pins out to a breadboard, installed the pull-up resistors, and I can then define the I2C port...

output from a scan:

import board
i2c = board.I2C()
i2c.try_lock()
i2c.scan()
True
[]

So close... but so far!

Meaning... it would appear that the firmware on the board is not actually implementing the I2C interface yet.
It's possible that one must somehow wake up the I2C mode, but I do not yet see any way to do that. I would think if there was a valid I2C interface, I would first have to see the device at an address before I could tell it to start sending information.

sigh

So... I physically connected D3 to to A1, and D2 to A0.
I then set D2 and D3 on the Wio Terminal side to inputs, to ensure there would be no conflicts:

led2 = digitalio.DigitalInOut(board.D3)
led2.direction = digitalio.Direction.INPUT
led1 = digitalio.DigitalInOut(board.D2)
led1.direction = digitalio.Direction.INPUT

I then defined the UART on the Wio Terminal side using A0 and A1.
The same data will go to D2 and D3, but I can't see it there as a uart.
I can see it at A0 and A1. ;)

uart = busio.UART(board.A0, board.A1, baudrate=9600)
time.sleep(.5)
print(uart.readline())
time.sleep(.5)
print(uart.readline())
time.sleep(.5)
print(uart.readline())
time.sleep(.5)
print(uart.readline())

output:

b'55\r\n'
b'096,,153\r\n'
b'.000,A,A5E\r\n'
b',,33,00,096,,153\r\n'
b'7\r\n'
b'6,,153\r\n'
b'A5D\r\n'
b',096,,1*53\r\n'
b'55\r\n'
b',096,,153\r\n'
b'5B\r\n'
b'168\r\n'

So... it is alive!

I use one of these to split the connector out in between the wio terminal and the lora chassis.

https://www.amazon.com/dp/B08C2DJBT2?psc=1&smid=AOP0CH6UTUPHT&ref_=chk_typ_imgToDp

I may be able to make a simple adapter... frankly I could build a large battery to power this in the field and include these two jumpers. I could also solder jumpers into the Lora chassis. It's not hard... it is just frustrating that I can't publish software for the world to use because Seeed chose a set of pins that I cannot easily read from Circuitpython.

Ideally a future revision of the Lora chassis would have the I2C and I can just use that... but for now at least I can play with it.

Seeed likely never thought about not using a software uart... even though doing it this way likely is more efficient in terms of actual device cycles. I would much rather be using the device cycles to draw stuff on the screen and interact with peripherals than smashing bits on a serial interface.

If you want, I would be happy to look at what the shipping costs would be to send you one of these boards. I was so happy when I found your examples... searching all over to find them. You really should get an E5 mini so you can talk back and forth between a raspberry pi and the wio terminal. I do have that example working over Lora... it's really not hard at all.

I probably won't send you one of the Lora chassis for the Wio Terminal if I can't afford it, but I would bet I can afford it. If you want to tell me where to send you such a package, I can try.

Would the import process require you to pay money to receive it, and would customs have to know exactly what is in the package? Sometimes that happens.. and I would not want that to happen to you.

Alternatively, I actually got these shipped from Seeed from out of country. I could look into just shipping it directly to you from Seeed. They are probably closer to you than I am.

Let me know your thoughts... it would be nice to collaborate with someone on some Lora items.

My use case is this: Have a traveling node and a node at home. As the traveling node travels, it picks up messages, and delivers those messages to others... digitally, over Lora. A digital, Lora mailman. No internet required. There really are cases in some countries where this could be very useful... remote areas in Africa where people do visit.. but there is no infrastructure like the internet.

Anyway... Thanks for listening.. and motivating me to work harder. My background is in Electrical Engineering.. so the hardware side of adding resisters and doing the soldering is the easy part for me... ;)

[t-ikegami]

Firstly, congratulation for getting signals! If you are to make an adapter, my recommendations are:

1. Avoid using A0/A1 for UART
   A0/A1 is used for the precious grove port on the right side of Wio Terminal. Other SERCOM capable pins (like MISO/MOSI) may better be used.
2. Add 2.8 <-> 3.3V level converter
   GPS chip works at 2.8V. Strangely, the level converters are installed for I2C pins, but not for UART pins. As far as the chassis works with soft-serial, however, the level conversion may not be necessary.

One concern is that the signal caught doesn't look like NEMA format. Could you try the following code?

import board
import busio

uart = busio.UART(board.A0, board.A1, baudrate=9600, receiver_buffer_size = 256)
while True:
  print(uart.readline())

• Default timeout of UART is 1 sec, which will be enough.
• Default buffer size is 64, which might be too short.
• digitalio stuff on D2/D3 is not necessary (I think they are harmless, though).

For the I2C stuff, I googled to found:
https://forums.quectel.com/t/l76-lb-firmware-files-documentation/8956
I2C should be enabled with this firmware, though UART output may be lost.

I really do want to play with the fancy chassis, with Lora and GPS integrated. And yes, I can buy it directly from Seeed. Unfortunately however, to test the Lora part will be super MENDOKUSAI (=cumbersome) in Japan; that Lora module is not authorized by the government, and personal registration is necessary. Sigh. That's the reason why the chassis is not available on the street, I guess.

Anyway, I'm happy to hear that my examples help. I think CircuitPython is very well designed, but working examples are limited.

[KenSamson]

I opened the battery board that I had here... and noticed that it has an I2C option too... so with that connected, I went ahead and did another scan... showing only the battery board item.

It does not look like the gps is talking in the I2C buss, and it is not clear to me exactly why.... it could be the firmware was not quite ready for I2C so they don't list it as the primary interface for now.

import board
i2c = board.I2C()
i2c.try_lock()
i2c.scan()

True
[85]

As requested.... in this case I do not yet think it has a GPS fix... FYI. If that is interesting I can re-send more with a GPS fix obtained. I've not been letting it run all the time until I figure out what to do about the voltage mismatch. It may be close enough to not worry about.. but I'm not all the way convinced of that yet.

I will probably try to use an adafruit GPS library here before long.. it actually looks very simple to use.
I have not looked into the voltage difference much yet... it seems odd that they would wire something together if the voltages are not compatible.

import board
import busio

uart = busio.UART(board.A0, board.A1, baudrate=9600, receiver_buffer_size = 256)
while True:
print(uart.readline())
b'$GNRMC,000122.870,V,,,,,0.00,0.00,060180,,,N,V28\r\n'
b'$GNVTG,0.00,T,,M,0.00,N,0.00,K,N2C\r\n'
b'$GNGGA,000122.870,,,,,0,0,,,M,,M,,58\r\n'
b'$GNGSA,A,1,,,,,,,,,,,,,,,,11D\r\n'
b'$GNGSA,A,1,,,,,,,,,,,,,,,,418\r\n'
b'$GPGSV,1,1,00,164\r\n'
b'$BDGSV,1,1,00,175\r\n'
b'$GNGLL,,,,,000122.870,V,N6A\r\n'
b'$GNRMC,000123.870,V,,,,,0.00,0.00,060180,,,N,V29\r\n'
b'$GNVTG,0.00,T,,M,0.00,N,0.00,K,N2C\r\n'
b'$GNGGA,000123.870,,,,,0,0,,,M,,M,,59\r\n'
b'$GNGSA,A,1,,,,,,,,,,,,,,,,11D\r\n'
b'$GNGSA,A,1,,,,,,,,,,,,,,,,418\r\n'
b'$GPGSV,1,1,00,164\r\n'
b'$BDGSV,1,1,00,175\r\n'
b'$GNGLL,,,,,000123.870,V,N6B\r\n'
b'$GNRMC,000124.870,V,,,,,0.00,0.00,060180,,,N,V2E\r\n'
b'$GNVTG,0.00,T,,M,0.00,N,0.00,K,N2C\r\n'
b'$GNGGA,000124.870,,,,,0,0,,,M,,M,,5E\r\n'
b'$GNGSA,A,1,,,,,,,,,,,,,,,,11D\r\n'
b'$GNGSA,A,1,,,,,,,,,,,,,,,,418\r\n'
b'$GPGSV,1,1,00,164\r\n'
b'$BDGSV,1,1,00,175\r\n'
b'$GNGLL,,,,,000124.870,V,N6C\r\n'
b'$GNRMC,000125.870,V,,,,,0.00,0.00,060180,,,N,V2F\r\n'
b'$GNVTG,0.00,T,,M,0.00,N,0.00,K,N2C\r\n'
b'$GNGGA,000125.870,,,,,0,0,,,M,,M,,5F\r\n'
b'$GNGSA,A,1,,,,,,,,,,,,,,,,11D\r\n'
b'$GNGSA,A,1,,,,,,,,,,,,,,,,418\r\n'
b'$GPGSV,1,1,00,164\r\n'
b'$BDGSV,1,1,00,175\r\n'
b'$GNGLL,,,,,000125.870,V,N6D\r\n'
b'$GNRMC,000126.870,V,,,,,0.00,0.00,060180,,,N,V2C\r\n'
b'$GNVTG,0.00,T,,M,0.00,N,0.00,K,N2C\r\n'
b'$GNGGA,000126.870,,,,,0,0,,,M,,M,,5C\r\n'
b'$GNGSA,A,1,,,,,,,,,,,,,,,,11D\r\n'
b'$GNGSA,A,1,,,,,,,,,,,,,,,,418\r\n'
b'$GPGSV,1,1,00,164\r\n'
b'$BDGSV,1,1,00,175\r\n'
b'$GNGLL,,,,,000126.870,V,N6E\r\n'
b'$GNRMC,000127.870,V,,,,,0.00,0.00,060180,,,N,V2D\r\n'
b'$GNVTG,0.00,T,,M,0.00,N,0.00,K,N2C\r\n'
b'$GNGGA,000127.870,,,,,0,0,,,M,,M,,5D\r\n'
b'$GNGSA,A,1,,,,,,,,,,,,,,,,11D\r\n'
b'$GNGSA,A,1,,,,,,,,,,,,,,,,418\r\n'
b'$GPGSV,1,1,00,164\r\n'
b'$BDGSV,1,1,00,175\r\n'
b'$GNGLL,,,,,000127.870,V,N6F\r\n'

[t-ikegami]

Firstly, I recommend not to paste the raw NMEA data, unless you are to disclose your location to the world.

I think you succeeded to get NMEA data from UART. My guess is that, at the rate of 9600 baud, level conversion is not necessary; 2.8 V is high enough for 3.3 V logic. I'm not familiar with the NMEA data, but the GPS module does not seem to catch any satellite signals. If you put the module in an open area for about 5 min, it will start generating valid NMEA sentences (ending with checksum pattern of "*XX").

Since you got NMEA data from UART, the GPS firmware may not aware I2C. It'll be better to test adafruit_gps.py with the current settings (UART with jumper wires). Later, you can burn the alternative firmware on the GPS module and test the I2C stuff (without jumper wires). Adafruit_gps.py seems to support both.