This is a cache of https://discuss.96boards.org/t/uart0-issue-on-mezzanine-sensors/10736. It is a snapshot of the page at 2024-11-01T01:54:20.138+0000.
UART0 issue on Mezzanine Sensors - Mezzanine Support - 96Boards Forum

UART0 issue on Mezzanine Sensors

Products Support Mezzanine Support
,
#1

As described in the following picture, we would like to receive data from Grove GPS sensor to UART0_RX serial interface on Dragon Board 410c.

image
image1355×599 260 KB

Unfortunately, when using command “cat /dev/tty96B0” on Dragon Board 410c, it produced trash data and sometimes unexpectedly stopped:
20201126-trash-data

About the Mezzanine Sensors, we used Revision C and has programmed both P0 and P1 pins as Input using Arduino USBasp programmer.

About Dragon Board 410c, we used Linux environment download at: www.96boards.org (SD card image title > Option 2) and installed some packages from step 5 to step 7

Before receiving GPS data from UART0 serial port, we:

  1. Checked baud-rate, data, parity, stop bit. According to the GPS SIM28 schematic, the GPS sensor worked at 9600bps, 8-bit data, no parity, 1 stop bit. We set these settings on Dragon Board 410c => It still received trash data.
  2. Checked GPS sensor by connecting it to the ubuntu PC through USB serial => It worked OK.
  3. Checked Mezzanine Board => It worked OK too. We could burn boot-loader of ATMEGA328p and could use 3.3V I2C Grove Port.
  4. Checked the connection of Mezzanine Board and GPS data using Oscilloscope. The data signal (5V) probed at TX pin (plugged into Arduino Pin P1) of GPS sensor and data signal (1.8V) probed at Pin 7 (UART0_RX) of 40-pin Low Speed Header was visually the same.

Strangely, when we started to plug Pin 7 (UART0_RX) of 40-pin Low Speed Header on Mezzanine Sensors to (40-pin Low Speed Header of) Dragon Board 410c, data signal was extremely noisy.

You know, after trying many different cases, we found out that Dragon Board 410c could receive data if and only if we plugged the Oscilloscope probe in to the TX pin (plugged into Arduino Pin P1) of GPS sensor. If we unplugged it, the data became trash again.

Because Oscilloscope probe pins usually have internal resistor(s) in it. So, we started to add pull-up resistor (560Ohm/2) at TX pin (plugged into Arduino Pin P1) of GPS sensor. And It worked!!!
Note that the resistor value 560Ohm/2 was just a trial value. We did not know the exact value.

image
image1399×655 285 KB

Then, Dragon Board 410c could receive correct NMEA strings from Grove GPS device.
Note that the terminal was connected to the console debug port of Dragon Board 410c.
20201126-correct-data

Is this issue come from Mezzanine Sensors?
If so, could we update the pull-up resistor to the next version of Mezzanine Sensors?
I hope that this work-a-round helps.

Regards,
Loc Pham

#2

Hi @jmjobin,

Sorry for asking,
Is this issue the same as yours described in thread UART0 Android Sensors Mezzanine - #7 by jmjobin and The problem for UART0 on Dragonboard 410, Android 5.1.1?

Regards,
Loc Pham

#3

Wouldn’t it be smarter to use a USB GPS? You can get a GENUINE u-blox 8 USB receiver for about $10 rather than using that KNOCKOFF u-blox 5.

According to schematics, your GPS module has pullups on RX/TX, but small. You might be able to solve this problem by setting the pin mode on the microcontroller to input-pullup.

#4

Yes, it would be smarter to use a USB GPS. Unfortunately, based on the hardware specification, we must use Grove GPS connected on Mezzanine Sensors.

By the way, the GPS chip we’re using is SIM28, not from u-blox. It supports NMEA and u-blox 6 protocols.

About the input-pullup suggestion, I will try to program P0 and P1 pins as input-pullup pins using USBasp programmer.

#5

That’s why I referred to it as a KNOCKOFF. Its not an actual ublox – its a 3rd party PRETENDING to be a ublox.

Could you explain that better?

#6

I am sorry for making you confused. What I mean is using Grove GPS is our requirement. We would like to use Mezzanine Sensors as a middle-man between devices and our 96Boards custom board.

Regards,
Loc Pham

#7

That doesn’t clarify anything. WHY is that a requirement? It doesn’t serve a rational purpose.

#8

I tried programming P0 and P1 pins as input-pullup pins as the following sketch:

void setup() {
    pinMode(0, INPUT_PULLUP);
    pinMode(1, INPUT_PULLUP);
}

void loop() {}

But Grove GPS still outputs trash data on Dragon Board 410c. Note that the RESET LED is off when receiving GPS data, which means that the above sketch is already loaded into ATMEGA328p.

#9

Let me explain more details. We are implementing an application that monitors/controls sensors, such as: LEDs, Accelerometer, and GPS on Android 10. Our boards does not have any sensors connected and we do not want to have messy wiring in case we want to add more sensors in the future.

So, the connection layout is Grove sensors connected to the custom board via Mezzanine Sensors.

USB devices, for example: u-blox GPS, are OK but we do not want to interface with USB protocol. We want to interface with sensors via interfaces, like: I2C, SPI, or UART.

#10

USB GPS uses CDC-ACM protocol, which emulates UART at /dev/ttyACM#. Therefore with a USB GPS, you will still interact with the GPS as if it were UART. The only difference for you will be that the wiring is easy, clean, and actually works.

You’re going to want to use GPSd as your HAL in Android in order to make the GPS function. gpsd / gpsd · GitLab

#11

Im wondering if enableling the onboard pullups of the MCU would help.

#12

Per my suggestion, he has already tried. That’s what “input-pullup” means. But the real bottom line is that he’s implementing a bad plan that needlessly increases complexity, makes the result much more fragile, and creates issues.

#13

Im just wondering since i never ran into problems using UART on a Atmega328 e.g never had a problem requiring a Pull-Up.

#14

He isn’t using UART on the microcontroller. He’s using UART on the SBC. The microcontroller is only part of the picture because the UART pins of the microcontroller are wired to the UART pins of the SBC. The purpose of putting the pins input-pullup is to see if the added power from the microcontroller could boost the drive strength of the GPS module enough to make the level shifter happy.

In a normal UART scenario, you have;
SBC-TX —> Peripheral-RX and SBC-RX <— Peripheral-TX.

In this scenario, you have;
SBC-TX —> (Peripheral-RX AND Microcontroller-RX) and SBC-RX <— (Peripheral-TX AND Microcontroller-TX).

But more importantly than that, the UART is being level shifted 1.8v <–> 5.0v on the sensors mezzanine by TXB0108, which requires input drive strength of 2 mA – this is within the output capabilities of the microcontroller (40 mA per pin), but not within its pull-up capability (~0.1 mA). His GPS module also has level shift 5.0v <–> 3.0v, but it has 5.0v drive via 10k resistors generating only 0.5 mA drive strength – that’s not enough for the TXB0108. Together with the microcontroller pull-up, the total drive strength will still only be ~0.6 mA. The GPS really should have between 1k and 2k resistors for this to work.

1 Like
#15

@loc_pham – actually, there is another important reason why you really should NOT wire the GPS up like that; doing so blocks all communication between the SBC and the microcontroller, since the microcontroller and the GPS cannot share UART lines. That basically means that all of the plugs connected to the microcontroller will be useless to you.

1 Like
#16

Thank you for your suggestion. After considerations, I think using GPS USB is much more suitable.

We will check it out.