Solo un pequeño FYI para referencia futura en caso de que alguien siga el camino por el que acabo de pasar. He usado con éxito el ZED-F9P como estación base GNSS RTK para mi receptor Trimble 372, e imagino que lo que he aprendido funcionará con cualquier receptor Trimble que pueda recibir datos RTCM de una fuente RS232 externa en el puerto C. Para una corrección solo GPS, Trimble parece funcionar con los tipos de mensaje 1005 (o 1006), 1008 y 1077. Para una corrección GPS y Glonass, Trimble parece funcionar con 1005 (o 1006), 1008, 1077, 1087 y 1230.
El tipo de mensaje que Trimble requiere y que no está disponible en el ZED-F9P es 1008, que es "Descriptor de antena". Por qué Trimble necesita esto, no lo sé. Escribí un simple programa Python que toma datos RTCM como entrada y genera los datos directamente, pero después de cada mensaje 1005 o 1006, genera un mensaje 1008 ficticio (ficticio en el sentido de campos en blanco, vacíos). Con esto agregado al flujo RTCM, el 372 adquiere una corrección RTK con bastante rapidez.
Pienso convertir este programa de Python a C y ejecutarlo en un arduino, que estará entre el ZED-F9P y la radio de la estación base, o entre la radio del rover y el receptor Trimble. Me inclino por el primero para que no se requiera nada especial en el receptor Trimble.
Aquí está el código Python, que toma datos en la entrada estándar y genera en la salida estándar:
Para fines de prueba, uso socat para leer de un puerto serie, pasar los datos a través de este pequeño programa y escribirlos en otro puerto serie, conectado a la máquina:
Tal vez alguien encuentre esto útil. Publicaré el código arduino en los próximos días.
El tipo de mensaje que Trimble requiere y que no está disponible en el ZED-F9P es 1008, que es "Descriptor de antena". Por qué Trimble necesita esto, no lo sé. Escribí un simple programa Python que toma datos RTCM como entrada y genera los datos directamente, pero después de cada mensaje 1005 o 1006, genera un mensaje 1008 ficticio (ficticio en el sentido de campos en blanco, vacíos). Con esto agregado al flujo RTCM, el 372 adquiere una corrección RTK con bastante rapidez.
Pienso convertir este programa de Python a C y ejecutarlo en un arduino, que estará entre el ZED-F9P y la radio de la estación base, o entre la radio del rover y el receptor Trimble. Me inclino por el primero para que no se requiera nada especial en el receptor Trimble.
Aquí está el código Python, que toma datos en la entrada estándar y genera en la salida estándar:
Code:
#!/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()
Code:
socat /dev/ttyUSB1,b57600,raw - | ./trimbleadd1008.py | socat - /dev/ttyUSB2b,38400,raw
