Group Actions
Engagement
  • Author Author: Jan Cumps
  • Date Created: Date Created
  • Views 396 views
  • Likes 7 likes
  • Comments 8 comments
Related
Recommended

Fun With UART, Global Navigation Satellite Systems (GNSS) and Teseo III

Jan Cumps

This article is related to  Fun With Arduino, Global Navigation Satellite Systems (GNSS) and Teseo III . At a lower level though: interaction with the UART interface. The "Fun with Arduino" post of  provides an Arduino sketch to talk to a Teseo-LIV3. That firmware uses UART to get info off the GPS. I'm going to do some of these things from a terminal. Read what the Teseo sends. And try to control that stream of info.

image

I'm investigating this to understand how this GPS behaves. I'm writing an I2C program for it, and it's hard to understand why and how I receive data. Fortunately, the I2C and UART interface are the same, except for the transport layer. Because it's easier to free-wheel a conversation with a terminal over UART, I'm going that way today. For a selected number of commands, I have to use another bit, to indicate I'm using the UART interface. But that's where the difference in logic ends.

Instead of having to go through a flow of  code-change, build and inspect i2C trafic cycle,
I can test all interactions via the serial monitor. And that's really easier.

Hardware needed:

  • a UART (3.3V) to USB COM Port converter. I used a picoprobe. Any pass-through UART to USB will work.
  • 5V power. Also delivered by that picoprobe in my setup.

Commands I've tested:

$PSTMSRR: reset

$PSTMSAVEPAR: save current settings in flash

$PSTMGPSSUSPEND: stop engine

$PSTMGPSRESTART: start engine

$PSTMCFGMSGL,0,1,0,0: clear UART list (this is the only one that's UART specific in my scenario. For I2C the first parameter is 3 instead of 0.

$PSTMSETPAR,1227,1,2: disable overeager messaging

$PSTMRESTOREPAR: restore to original settings. Undo flash write

$PSTMNMEAREQUEST,100000,0: request location

$PSTMNMEAREQUEST,40,0: request time

Here's the result of a few exchanges:

image

image:I managed to tame the output. It only returns what I ask, instead of a regular flow of all data.

That's it. A simple post that shows that you can control the behaviour in a very similar way with I2C or UART. 

Parents

  • I found a command that doesn't nicely fit in my reply-response paradigm: GPGSV.

    Unlike GPGLL and GPRCM, it returns multiple lines. That means I have to adapt the reader functions and the class of my Teseo lib to deal with such scenarios...

    ---- Sent utf8 encoded message: "$PSTMNMEAREQUEST,80000,0\r\n" ----
    $GPGSV,3,1,12,03,82,292,,02,54,132,21,17,48,278,,21,37,130,*7A
    $GPGSV,3,2,12,04,37,183,,19,33,308,19,28,20,062,,31,16,096,*7C
    $GPGSV,3,3,12,06,11,302,,22,07,267,,09,07,204,,32,05,037,*71
    $GLGSV,2,1,07,88,66,314,20,72,65,044,26,87,51,144,20,65,51,219,*62
    $GLGSV,2,2,07,71,15,039,29,81,13,322,32,80,11,358,35,,,,*58
    $PSTMNMEAREQUEST,80000,0
  • in reply to Jan Cumps

    this turned out to be a lucky event. The fact that some commands return multiple lines and a status line, forced me to build a multiline capable reader.

    But in essence, every "query" command returns at least two lines. The reply (1 line in case of a simple command) and a status line..

    Solving the GPGSV took care that my code could also handle a normal command better.
    I created code that understand (1..n) reply lines and a status line. Should handle all cases, including validation


Comment
  • in reply to Jan Cumps

    this turned out to be a lucky event. The fact that some commands return multiple lines and a status line, forced me to build a multiline capable reader.

    But in essence, every "query" command returns at least two lines. The reply (1 line in case of a simple command) and a status line..

    Solving the GPGSV took care that my code could also handle a normal command better.
    I created code that understand (1..n) reply lines and a status line. Should handle all cases, including validation


Children