Issue with Reading GNSS Data via UART

Dear Support,

I am writing to seek assistance with an issue that I have encountered while using my Verdin iMX8M Mini Quad 2GB Wi-Fi/Bluetooth IT device running TorizonCore 5.

Specifically, I have modified the device tree for UART 2 by using GPIO3 and GPIO4 with a pinctrl configuration

	pinctrl_uart3: uart3grp {
		fsl,pins = <
			MX8MM_IOMUXC_UART3_RXD_UART3_DCE_RX		0x146	/* SODIMM 210 */
			MX8MM_IOMUXC_UART3_TXD_UART3_DCE_TX		0x146	/* SODIMM 212 */
		>;
	};

and details of UART2

/* Verdin UART_2 */
&uart3 {
	status = "okay";
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_uart3>;
	fsl,uart-has-rtscts;
};

, and I am attempting to use the Verdin UART_2 to read data from a GNSS device. However, when I try to read the data using the ‘cat’ command, the output appears messy and incorrect.

GNRMC,155426,
second parameter shows the time for example 15:54:26

torizon@verdin-imx8mm-07219010:~$ cat  /dev/verdin-uart2                        $GNRMC,155426.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*17

$GNRMC,155426.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*17
$GNRMC,155426.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*17
$GNRMC,155427.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*16

$GNRMC,155426.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*17
$GNRMC,155427.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*16
$GNRMC,155426.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*17
$GNRMC,155427.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*16
$GNRMC,155426.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*17
$GNRMC,155428.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*19

$GNRMC,155427.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*16
$GNRMC,155426.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*17
$GNRMC,155428.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*19
$GNRMC,155427.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*16
$GNRMC,155426.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*17
$GNRMC,155429.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*18

$GNRMC,155428.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*19
$GNRMC,155427.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*16
$GNRMC,155426.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*17
$GNRMC,155429.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*18
$GNRMC,155428.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*19
$GNRMC,155427.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*16
$GNRMC,155426.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*17
$GNRMC,155430.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*10

Upon further investigation, I have found that if I remove the TX pin (GPIO4), the GNSS data can be read correctly. I am confused as to why this is the case, as I am not sending any echo messages on this pin.

when GPIO4 is disconnected

torizon@verdin-imx8mm-07219010:~$ cat  /dev/verdin-uart2
$GNRMC,160118.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*19

$GNRMC,160119.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*18

$GNRMC,160120.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*12

$GNRMC,160121.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*13

$GNRMC,160122.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*10

$GNRMC,160123.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*11

$GNRMC,160124.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*16

$GNRMC,160125.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*17

$GNRMC,160126.000,A,5153.2893,N,00824.1567,W,0.00,292.13,290323,,,D,V*14

I would greatly appreciate any guidance or suggestions you may have to help resolve this issue.

I have tested the Verdin iMX8M Mini Quad 2GB without WIFI, and I do not recall encountering this issue. However, I am unable to test it again as the device is currently broken.

Thank you in advance for your assistance.

Best regards,
Mehrdad

I’m sorry but I can see any significant difference in cat command output in both cases. Could you please explain what’s wrong with the first case?

What do you mean saying “remove pin” ? Have you just disconnect it from GNSS receiver or remove it from Device Tree?

Hi @alex.tx ,
I appreciate your time so much.
In the images, you can see that the time is not accurate when the GPIO4 TX with wire is connected to the RX of GNSS, as you can see from the images. why it shows a couple of times the response of GNRMC,

and when the TX pin (GPIO4)is disconnected by disconnecting the wire

image

Probably, when the TX (GPIO4) is connected, some issues will arise.

Also, the baud rates are the same.

Best regards,
Mehrdad

As you mentioned

So on the first attempt time was 15:54 an the second attempt time was 16:01. Can’t see anything wrong there. Any way - Since you are receiving a proper ASCII string UART communication in both cases looks fine. Why it shows “wrong” time when TX (GPIO4) is connected? Could be a GNSS receiver issue . Please check its datasheet for details.

Hi @alex.tx ,

I appreciate your help. Would it be necessary to add the required lines for GNSS to the DT, like those below for RS485? I mean not these lines but some necessary ones that I do not know :slight_smile:

&uart2 {
    status = "okay";
    linux,rs485-enabled-at-boot-time;
    rs485-rts-active-low;
    rs485-rx-during-tx;
};

Best regards,
Mehrdad

It depends on your GNSS receiver UART interface requirements. Please check its datasheet .

Dear @alex.tx ,

I hope you are well.

Using Terminal software and an oscilloscope, I checked the GNSS UART response [by using a USB terminal cable] and sent commands to the GNSS using my recent experience.

As you can see from the image below, I have been sending commands to the GNSS every 2 seconds and receiving responses based on those commands. The red line represents the RX of the GNSS, while the blue lines represent the TX and the response.

For example, when I asked for an RMC command, the GNSS responded as follows:

$GNRMC,160827.000,A,5153.2893,N,00824.1627,W,0.00,81.53,030423,D,V20
$PMTK001, 314,3
36 [Orange Square]

Initially, I was able to send and receive data successfully through the terminal software and GNSS by using the USB to serial cable.

In a later attempt, I connected only two pins to UART2 of an i.MX8 Mini with WiFi directly.

Then I tried UART2 and everything worked fine UART2 and GNSS

By using the “cat” command, you can observe the messy appearance and understand why the two lines are talking. I did not send anything with echo, and all ports are closed, I was simply trying to read through the “cat” command.

Best regards,
Mehrdad

Nice picture but what are tying to say/prove by it?

Hi @alex.tx ,

I can set configurations and receive responses from the GNSS without any problems by using a UART to serial cable and terminal software. However, when using the Verdin i.MX8 Mini and the “cat” command, there seems to be an issue.

Best regards,
Mehrdad

"Could you please clarify in more details?

  • I still didn’t get what you issue is. Both texts you received looks OK from UART receiving point of view.
    _what configuration you are talking about saying : I can set configurations and receive responses from the GNSS without any problems by using a UART

If you can receive responses from the GNSS without any problems by using a UART - what are you trying to fix?

Mehrdad,

  • What GNSS module are you using?
  • On the GNSS module, where are ALL of the pins tied to on the Verdin board?
  • Attach your current complete device tree file

– Dave

Hi @alex.tx ,

  • If you can receive responses from the GNSS without any problems by using a UAR T - what are you trying to fix?

I apologize if my explanation was unclear before. I did two tests with my GNSS L76_l Quectel evaluation board.

First, I used a UART-to-serial cable and connected it to the GNSS evaluation board to send and receive RMC commands, and the response was successful. This leads me to believe that the GNSS module is functioning properly. In this test, I did not use the Verdin board.

Secondly, I connected the GNSS UART RX and TX to GPIO 3 and 4, which I modified DT for UART usage. When I used the “cat” command in Linux to view /dev/ttymxc2, both lines appeared to be busy, as shown in the image below.

Additionally, when I monitored the GNSS module with an oscilloscope, the response was satisfactory. The module sent the expected package every second, without using the “cat” command image below.

image

the cat command that I used to see the response on Linux:
cat < /dev/ttymxc2

also, I tried

dd if=/dev/ttymxc2

image

Both commands did not work well. yes the UART communication is working fine, no issues with characters and package names but it should send them one by one.

As you saw before and in the lines below it shows 151513 (second 13) next line is 151514(second 14) again 151514 again151514 [The test was conducted at 15:15:13 and the date is 03/04/2023 :slight_smile: ]
It is obvious something is wrong

torizon@verdin-imx8mm-07219010:~$ cat < /dev/ttymxc2
$GNRMC,151513.000,A,5153.2875,N,00824.1605,W,0.00,111.58,030423,D,V*13

$GNRMC,151514.000,A,5153.2875,N,00824.1605,W,0.00,111.58,030423,D,V*14

$GNRMC,151514.000,A,5153.2875,N,00824.1605,W,0.00,111.58,030423,D,V14
$GNRMC,151514.000,A,5153.2875,N,00824.1605,W,0.00,111.58,030423,D,V
14
$GNRMC,151515.000,A,5153.2875,N,00824.1605,W,0.00,111.58,030423,D,V*15

$GNRMC,151514.000,A,5153.2875,N,00824.1605,W,0.00,111.58,030423,D,V14
$GNRMC,151515.000,A,5153.2875,N,00824.1605,W,0.00,111.58,030423,D,V
15
$GNRMC,151514.000,A,5153.2875,N,00824.1605,W,0.00,111.58,030423,D,V14
$GNRMC,151515.000,A,5153.2875,N,00824.1605,W,0.00,111.58,030423,D,V
15
$GNRMC,151514.000,A,5153.2875,N,00824.1605,W,0.00,111.58,030423,D,V*14

I appreciate your time and effort in assisting me.

Please let me know if I need any further experiments or tests done to resolve the issue.

Thank you again for your assistance.

Best regards,
Mehrdad

@Mehrdad ,

  • You might want to remove the line fsl,uart-has-rtscts from your device tree. It looks like you’re just using a 2-wire connection with any type of rts/cts connected.
  • Instead of using cat, maybe try using some sort of serial port monitor application like minicom that will set up the port for you with baud/stop/parity/mode. You might just be getting lucky with the config at this point and getting some data out.

Good luck,

– Dave

Dear Toradex Support,

I would like to inform you that the technical support case can be closed as I was able to receive assistance offline with the help of @josep.tx . We were able to resolve the issue with the following line:

stty -F /dev/ttymxc2 -echo
to disable the local echo for /dev/ttymxc2 ( or the UART that you eventually want to use), and try the cat command again. It should work correctly

Thank you for your time and efforts in trying to assist me with this matter.

Best regards,
Mehrdad