[torriem]

Just a quick little FYI for future reference in case anyone goes down the road I've just been on. I have successfully used the ZED-F9P as a GNSS RTK base station for my Trimble 372 receiver, and I imagine that what I've learned will work with any Trimble receiver that can receive RTCM data from an external RS232 source on Port C. For a GPS-only fix, Trimble seems to work with message types 1005 (or 1006), 1008, and 1077. For a GPS and Glonass fix, Trimble appears to work with 1005 (or 1006), 1008, 1077, 1087, and 1230.

The message type that Trimble requires that isn't available on the ZED-F9P is 1008, which is "Antenna Descriptor." Why Trimble needs this I don't know. I wrote a simple Python program that takes RTCM data as input, and outputs the data straight out, but after each 1005 or 1006 message, it outputs a dummy 1008 message (dummy as in blank, empty fields). With this added to the RTCM stream, The 372 acquires an RTK fix fairly quickly.

I intend to convert this python program to C and run it on an arduino, which will either stand between the ZED-F9P and the base station radio, or stand between the rover radio and the Trimble receiver. I am leaning towards the former so that nothing special is required on the Trimble receiver.

Here's the Python code, which takes data on standard in and outputs to standard out:

#!/usr/bin/python3

import sys

while True:
    data = sys.stdin.buffer.read(1)
    while (data != b'\xd3'):
        data = sys.stdin.buffer.read(1)

    length_data = sys.stdin.buffer.read(2)
    length = (length_data[0] << 8) + length_data[1]
    packet_data = sys.stdin.buffer.read(length)
    crc24_data = sys.stdin.buffer.read(3)

    message_number = (packet_data[0] << 8) + packet_data[1]
    message_number >>= 4

    sys.stdout.buffer.write(b'\xd3')
    sys.stdout.buffer.write(length_data)
    sys.stdout.buffer.write(packet_data)
    sys.stdout.buffer.write(crc24_data)
    sys.stdout.flush()

    if message_number == 1005:
        # blank 1008 message for Trimble
        sys.stdout.buffer.write(bytes([0xd3,0x00,0x06,0x3f,0x00,0x00,0x00,0x00,0x00,0x99,0x25,0xca]))

        sys.stdout.flush()

for testing puroses, I use socat to read from one serial port, pass the data through this little program, and write it to another serial port, connected to the machine:

socat /dev/ttyUSB1,b57600,raw - | ./trimbleadd1008.py | socat - /dev/ttyUSB2b,38400,raw

Maybe someone will find this useful. I'll post arduino code in the next few days.

 

[torriem]

I've decided to do the injection of message type 1008 on the base station. That way roving clients just work.

So the way I'm thinking of doing this is to have an arduino uno on the bottom, and then the SimpleRTK2 board on that, and then the radio module on an adapter board on top of that. That way the uart1 port of the Simple RTK2 plugs directly into the Arduino Uno's main serial interface, and the alternate serial TX pin will pass through on pin 9. The Uno pinout will provide 5V to the IOREF input of the SimpleRTK2. I will need to order some of of those stackable headers to solder to the SimpleRTK2.

Here's some code, which uses the AltSoftSerial library, but I think any of the software serial libraries will work for this simple application:

#include <AltSoftSerial.h>

/*
  Reads in a stream of RTCM3 data on the software serial
  port, outputs it to the built-in serial port.  If
  a message type of 1005 or 1006 is detected, a blank
  1008 message will be inserted into the output stream,
  which should allow a ZED-F9P RTK base station to work with
  Trimble roving receivers, which require 1008.

  Pin 8 is RX from the radio module (unused)
  Pin 9 is TX to the radio module

  Pin 0 is RX from the F9P
  Pin 1 is TX to the F9P (unused)

  For Uno or similar board. Other boards might require
  different pins for the AltSoftSerial port.  See the
  AltSoftSerial documentation for more information.
 */

// Blank RTCM3 type 1008 message
const char packet1008[12] = { 0xd3,0x00,0x06,0x3f,0x00,0x00,0x00,0x00,0x00,0x99,0x25,0xca };

AltSoftSerial mySerial(8,9); // RX, TX

void setup() {
    Serial.begin(57600);
    while (!Serial) {
    ; // wait for serial port to connect. Needed for native USB port only
    }

    // set the data rate for the SoftwareSerial port
    mySerial.begin(57600);
}

void loop() {
    byte c;
    int length;
    unsigned int type;

    int count;
    c = 0;

    //Look for start of RTCM3 message
    while (c != 0xd3) {
        if (Serial.available()) {
            c = Serial.read();
            mySerial.write(c); //pass it through to the radio
        }
    }
  
    //Okay we might have found one, lets get the length
    count = 0;
    length = 0;
    while (count < 2) {
        if (Serial.available()) {
            c = Serial.read();
            mySerial.write(c);
            length = (length << 8) + c;
            count ++;
        }
    }
    length = length & 0x07ff; //isolate only the least significant 10 bits
 
    //identify the message type
    count = 0;
    type = 0;
    while (count < 2) {
        if (Serial.available()) {
            c = Serial.read();
            mySerial.write(c);
            type = (type << 8) + c;
            count ++;
        }
    }
    type = type >> 4; //isolate type form the most significant 12 bits

    //Now pass through the rest of the message
    count = 0;
    while (count < length + 1) {
        //read in the message body, less the 2 type bytes, and then
        //the 3 CRC bytes, so length + 1.
        if (Serial.available()) {
            c = Serial.read();
            mySerial.write(c);
            count ++;
        }
    }

    if (type == 1005 || type == 1006) {
        //inject a 1008 message
        mySerial.write(packet1008, 12);
    }
}

 

[WTalen]

Is this set up feeding corrections to your Reach units as well? Thanks for posting this.

 

[torriem]

Despite my previous failed attempts, it appears that the Reach RS+ can use the F9P as a base station directly. At least it's working perfectly this morning for me. This 1008 injection is not required for the reach. I'll do some more experimenting and get back to you. I think previously I was using MSM4 messages, while now I've added MSM7 messages, which are redundant with the MSM4. I'll do a few tests and get back to you on this.

 

[torriem]

Yes the Reach RS worked great today with 1005, 1077, 1087, 1097, 1127, and 1230 on the base. Now the question is the best way to get the corrections to the Reach. I'm sending RTCM up to rtk2go, so I can enable ntrip on the Reach itself if it has internet access. I have tried bluetooth and using ntrip client on the phone, but I've have no luck with bluetooth on the Reach. Just doesn't connect.

 

[WTalen]

That's great to hear. I might have to try something similar in the future.

I've been able to get the Reach RS+ to send its location to my phone via bluetooth and enabling mock locations but I've never tried it the other way around with Lance Lefebure's NTRIP client. Hopefully it's something simple. Bluetooth is always finicky.

 

[torriem]

I got things soldered up and stacked nicely. The SimpleRTK2 is perfect for this, since it's an Arduino shield already. Everything is powered by a common 5v rail, which will be fed into the 5v in pin on the SimpleRTK. The SimpleRTK does not produce enough power to run the radio (requies 1 amp). The arduino might be able to, but that's a lot of load in the linear regulator. So I'll power this with an external 5v power supply.

The SimpleRTK2 sends rtcm3 over uart1, to pin 1 of the arduino on the bottom. The arduino injects 1008 messages and sends all the data back ip pin 9, which is connected to the radio's data in. The radio is a 1 watt 900 Mhz module from Digi that I salvaged from some other obsolete electronics (9Xtend, obsoleted by SX pro), running the hopping firmware at 112500 bps over the air. I will be using the Digi SX (10 mw) module on the rover unit(s), again with hopping firmware.

I'm just going to get it mounted in a box and then it will be ready to install in my shop. I'm not sure how long the GPS antenna cable can be (the antenna comes with a 15' cable), so it will likely be mounted inside the shop up near the roof. Eventually I might add an ESP32 board running ESPRTK to push to an NTRIP caster. For beta testing it will be radio only for now (I can always bridge to ntrip caster on a PC with another radio receiver plugged into USB).

 

[nutnut]

Congratulations for your achievement, how far do you think you can transmite with the 1 watt module

 

[torriem]

It's really just limited to line of sight. According to the Digi literature, you should be able to get up to 100 km and still get a coherent signal, if there are no obstacles between the transmitter and receiver. So it depends on your terrain and how tall your antenna mast is. At only about 8 metres, I can reach for several km easily, except for a few areas where hills block the line of sight. I plan to install the transmitting antenna on top of my shop on a small mast. Should everywhere on my farm, at most a few km. A nice tall 30 metre mast would be even better, and probably reach about 15-20 km in my flat country.

Another alternative for the difficult-to reach areas is to switch over to NTRIP over cell phone with a bluetooth serial adapter on the rover GPS. So far I'm having a hard time getting my cheap bluetooth serial modules to connect to my android phone though.

 

[Andreas Ortner]

https://github.com/eringerli/RpiNtripBase

there is a ready to use base with ntrip server including your 1008 inject for raspberry pi.

thanks to christian of the agopendevelop team!

 

[flywire]

... Trimble requires ... "Antenna Descriptor." Why Trimble needs this I don't know.

Maybe for Antenna Reference Point?

 

[torriem]

Could be. Seems to works fine with a blank 1008 message (empty fields or zeros).

 

[Dirty Harry]

Great thread guys!

I'm trying to get this up and running with an ArduSimpleRTKB and Drotek Sirius F9P receiver boards. Different systems integrators but the same ZED-F9P guts essentially.

Currently sending 1005, 1077, 1087, 1097, 1127 and 1230 MSM7 messages out via the USB port to a laptop running SNIP Lite. Then taking that stream and feeding it to my larger SNIP Pro Caster which is using the PFAT facility to add the 1008 message from another receiver stream. So not quite a dummy (empty) 1008 message there, but actually some descriptors in the message.

Unfortunately in testing with a AGCO/Trimble AG-382 (which should be the same hardware as a 372) results in a somewhat confused receiver. Not quite getting a proper fix and hold read and a weird distance to base reading (the default 50,000m).

Interestingly if I feed the 372 with another MSM7 stream from a Leica receiver, it is very happy and gets a fix in a few seconds. The only differences I can see is that the Leica MSM7 stream also contains 1006 instead of 1005 and has 1013 and 1033 messages in the stream in addition to 1077, 1087, 1097, 1127 and 1230.

Any thoughts as to what I should try next?

 

[Dirty Harry]

For what its worth, think I'm going to try adding 1033 messages (Receiver and Antenna Descriptors) from the other receiver into the u-blox stream, and see if the Trimble receiver is happy with that...

Edit:
(taken from the u-blox ZED-F9P Integration Manual)

The RTCM3.3 correction stream must contain the GLONASS code-phase biases message
(type 1230) or the Receiver Antenna Description message (type 1033) otherwise the GLONASS
ambiguities can only be estimated as float, even in RTK fixed mode.

....I just inspected the 1230 message coming from the u-blox receiver (Station 0) and compared it to the 1230 coming from the Leica receiver (Station 1492)....think I may be missing a (configuration) trick here!:

 

[Konrad]

I am trying to set up a base station as well with a F9P as base. I set up a SNIP NTRIP caster and push the stream via STRSVR into SNIP. With RTKLib‘s RTKNAVI I get quite good RTK fix.
But when I try to connect to my tractor with Trimble‘s AG382 installed I have the same problem. It shows NTRIP active but the distance to the base is the default 50,000 m. RTCM messages: 1004, 1012, 1006, 1008, 1033, 1077, 1087 and 1097.
What could be wrong with the setup?

 

[Dirty Harry]

I am trying to set up a base station as well with a F9P as base. I set up a SNIP NTRIP caster and push the stream via STRSVR into SNIP. With RTKLib‘s RTKNAVI I get quite good RTK fix.
But when I try to connect to my tractor with Trimble‘s AG382 installed I have the same problem. It shows NTRIP active but the distance to the base is the default 50,000 m. RTCM messages: 1004, 1012, 1006, 1008, 1033, 1077, 1087 and 1097.
What could be wrong with the setup?

Along the lines of my last post, I'm now suspecting my issue to the lack of fix using the AG-382 as rover and F9P as base may be due to empty/incomplete GLONASS code phase biases in message 1230 from the F9P.

You have an interesting mix of message types there. Some legacy (1004/1012) and some MSM7! Its not the best idea to mix both on the same stream - generally it's either legacy or MSM but not both.

 

[Konrad]

I am trying to set up a base station as well with a F9P as base. I set up a SNIP NTRIP caster and push the stream via STRSVR into SNIP. With RTKLib‘s RTKNAVI I get quite good RTK fix.
But when I try to connect to my tractor with Trimble‘s AG382 installed I have the same problem. It shows NTRIP active but the distance to the base is the default 50,000 m. RTCM messages: 1004, 1012, 1006, 1008, 1033, 1077, 1087 and 1097.
What could be wrong with the setup?

Along the lines of my last post, I'm now suspecting my issue to the lack of fix using the AG-382 as rover and F9P as base may be due to empty/incomplete GLONASS code phase biases in message 1230 from the F9P.

You have an interesting mix of message types there. Some legacy (1004/1012) and some MSM7! Its not the best idea to mix both on the same stream - generally it's either legacy or MSM but not both.

Thanks for letting me know. I changed to RTCM 3.1 only messages (1004, 1006, 1008, 1012, 1033) and it works now! I will do a field trial now. I think my problem was that I used an old RTKLIB version (b27) and updated to the latest b33 version of rtklibexplorer. The Glonass 1012 message was corrupted.

 

[Dirty Harry]

Great its working for you on the legacy MTs.

I would really like to get it working with MSM7 message direct from the receiver and just have to add a dummy 1008 like the OP has.

I’m still puzzled about the 1230 GLONASS code phase bias messages being zero/blank out of the F9P. Kind of suspect that’s causing the rover receiver some grief on getting a fix.

I may try switching off GLO messages completely from the stream out of the F9P and see if that helps matters.

 

[torriem]

....I just inspected the 1230 message coming from the u-blox receiver (Station 0) and compared it to the 1230 coming from the Leica receiver (Station 1492)....think I may be missing a (configuration) trick here!:

Very interesting. What program are you using to decode the message? I assume it was you that posted to the uBlox forum yesterday also? Hope you get an answer. Very curious.

 

[Dirty Harry]

Very interesting. What program are you using to decode the message? I assume it was you that posted to the uBlox forum yesterday also? Hope you get an answer. Very curious.

That's a snippet from the RTCM message viewer on the SNIP caster. Yes it was me posting on the u-blox forum.

I cannot fathom yet how to set/tweak/update or inspect how the u-blox receiver is calculating or generating the 1230 messages for GLO code phase biases. This thing has me stumped...I can get a fix from this using another u-blox rover (Emlid Reach RS2) although its a bit iffy, jumping from single solution to fix solution then back to single solution, not much float happening.

I've also tested MSM4 correction straight from an RS2 and I can get a fix pretty easily on a older ComNav T300 receiver, but with a AG-382 on the tractor it refuses to play ball.

It would appear the Ag Trimble receivers really only like MSM7 or legacy 1004/1012 messages - though apparently not the particular flavour of MSM7 from any of the u-blox receivers I have here....