Unicore UM980 support

[dosas]

Hello,

is there support or planned support for the unicore UM980?

Thanks

[semuadmin]

In terms of configuring Unicore receivers, I don't have a UM980 to hand (perhaps some kind soul from SparkFun or Ardusimple would care to donate one?), but if I understand correctly the Unicore receivers are configurable via TTY (ASCII text) commands, so it should be supported already via PyGPSClient's TTY Commands panel.

You can either enter the commands manually (with or without an XOR checksum), or save them as presets in the json configuration file and then select them from the drop-down list.

e.g. to configure the baud rate on COM1...

https://www.ardusimple.com/wp-content/uploads/2023/04/Unicore-Reference-Commands-Manual-For-N4-High-Precision-Products_V2_EN_R1.4-1.pdf

Give it a go and let me know how you get on.

Support for UM980 NMEA Secondary Antenna and Attitude messages (e.g. GPGLLH, HPD) in PyGPSClient will require an update to the pynmeagps library. This is currently on the backlog and I hope to introduce this in the next version over the next month or so.

Support for UM980 binary messages (e.g. PVTSLN) in PyGPSClient will require a new Python parser library, provisionally "pyunigps", as well as an update to the GNSSReader class in pygnssutils. I'll look into this as and when I have the time and motivation.

[dosas]

That sounds great.
I tried to configure my UM980 using PyGPSClient ASCII commands but somehow I could not get it to work.
I ended up using minicom to configure it successfully.

[semuadmin]

That sounds great. I tried to configure my UM980 using PyGPSClient ASCII commands but somehow I could not get it to work. I ended up using minicom to configure it successfully.

What exactly did you try? I've been sending ASCII commands to my UM981 (via PyGPSClient's TTY Commands panel) to enable various binary and ASCII data output messages and they all seem to work as expected (make sure you have CRLF and Delay ticked), e.g.

SATSINFOB COM1 1
AGRICB COM1 4
OBVSMB  COM1 4
GPSUTCB  COM1 4
PVTSLNB COM1 4
HWSTATUSA  COM1 10

The commands to put the UM981 into fixed Based Station mode and enable RTCM3 output also work as expected. e.g.:

mode base
rtcm1033 comx 10
rtcm1006 comx 10
rtcm1074 comx 1
rtcm1124 comx 1
rtcm1084 comx 1
rtcm1094 comx 1

These command examples can all be found in Table 1.1 of the following document:

https://www.ardusimple.com/wp-content/uploads/2023/04/Unicore-Reference-Commands-Manual-For-N4-High-Precision-Products_V2_EN_R1.4-1.pdf

[dosas]

My problem was, that I did not get confirmation if the command was successfull. When using minicom I saw the full return code.

[semuadmin]

My problem was, that I did not get confirmation if the command was successfull. When using minicom I saw the full return code.

Understood. FYI if you select TTY ('teletype') Protocol in PyGPSClient, the console effectively acts like a standard minicom terminal, allowing you to see the raw ASCII $command responses e.g.

If you're NOT in TTY mode, the command responses will appear as Unknown protocol header b'$c'. errors, as they're not recognised as standard NMEA, UBX or RTCM sentences.

The main advantages of using PyGPSClient over minicom or another basic terminal program are:

• you can store commands or command sequences as presets, obviating the need to type them in manually.
• you can view the parsed binary output immediately* - in minicom it will simply appears as gibberish \xaaD\xb5\L... etc.

* once pyunigps is integrated into PyGPSClient in the next version.

There is a short instructional video covering this procedure on my YouTube channel. It uses a Septentrio device for demonstration purposes, but the same procedure can be used for Unicore UM* series devices.

[dosas]

Nice!

[semuadmin]

Nice!

In the illustration above I'm using the same port for both data output and configuration, so my command responses are mixed in with a load of raw NMEA data.

Ideally, if your UM98* development board implements two serial ports (including or in addition to a USB port), one would typically assign 'COM1' (e.g. TXD2/RXD2) as the data output port and COM2 (e.g. TXD3/RXD3) as the configuration port (as per the video). This way you ONLY see commands and their responses via the TTY console on COM2, rather than a whole load of raw NMEA or UNI data mixed in. This makes it much easier to monitor responses. However, if you send valid TTY commands 'blind', they will still work - you just won't see the acknowledgement.

I've noticed that my UM981 generally sends OK responses immediately, but PARSED FAILD responses can sometimes can a while.