sparkfun / SparkFun_LoRaSerial

A simple to use radio modem for long distances using LoRa.
https://docs.sparkfun.com/SparkFun_LoRaSerial/
Other
17 stars 6 forks source link

Getting garbage data with RTK facet on radio port #1

Closed coalman321 closed 2 years ago

coalman321 commented 2 years ago

Hi, i just picked u this radio kit to try with an RTK facet as a 915MHz local correction system. In trying this out, I have been unable to get valid RTCM data over the serial link. The modules and configurations do seem to be valid for sending data between USB connections of the two LoRaSerial modules, so the issue seems to be isolated to the UART connection.

Setup:

This procedure, as well as some other variations of air speed (on the LoRaSerial modules) and baud rates (on all 3 devices) produces similarly garbage output. Personally, I'm not quite sure where to go from here beyond inspecting the raw packets. Any help would be greatly appreciated.

Also, something that might be helpful is a way to use the USBC port as a debug port when connected to the UART connector (for echoing received data and such).

nseidle commented 2 years ago

This is the main application for LoRaSerial. Thanks for reporting a well described issue.

Your setup sounds good. However, RTCM is a binary encoded packet. It will appear as garbage viewed in a serial terminal. If you have a 2nd Facet, RTK Express, Surveyor, ZED-F9P, ZED-F9R, etc, available, you should be able to pipe the RTCM into that u-blox device and then view the successful RTCM packet reception via u-center MON-COMM message.

FWIW the default settings of LoRaSerial support RTCM packet delivery. ie, the default UART speed of 57600bps is the default for the RTK product line, and the default AirSpeed of 4800bps will support the ~500 bytes per second that RTCM needs.

Also, something that might be helpful is a way to use the USBC port as a debug port when connected to the UART connector (for echoing received data and such).

This is an interesting idea. What debug information would you want to see?

coalman321 commented 2 years ago

Ah, that makes a lot more sense now. That definitely might be a helpful note to put somewhere. I was expecting output akin to the standard NMEA sentences. Ill try actually connecting the two and make sure that works in a few hours with the default settings again. I had been observing some glitchy behavior with the settings (not saving, or causing the radio link to drop until the modules undergo a reset) and was wondering if it somehow wasn't actually getting saved to memory, or reconfiguring the UART. Sorry for the confusion on that.

As to the debug information, being able to use the USB port to change radio settings as well as possibly see an echo of the incoming and outgoing traffic was my original idea. You would probably only want to do this though if the USB is connected at or during boot. Otherwise it would default to off and the modules would act normally.

nseidle commented 2 years ago

an echo of the incoming and outgoing traffic was my original idea

Incoming traffic is sent to both UART and USB ports. Echoing outgoing traffic would have to be marked as such (otherwise it looks like incoming).

You would probably only want to do this though if the USB is connected at or during boot

There are quite a few applications where the radio is permanently attached via USB (ie a GNSS reference station) for serial traffic. Auto-detecting intention will be difficult. That said, there is command ATS20=1 that will enable debug messages. We would need to add some additional watermarking to echo other port data but let's make sure you're up and running before we start going down that feature path.

coalman321 commented 2 years ago

Yes, I was looking for a way to echo the outgoing traffic from the UART. Using ATS20 (or possibly another command?) might work better than auto-detecting intent in that case. My concern with turning it on via other means without an actual USB connected could cause more power or resources to be used up for lower power or constrained installations.

coalman321 commented 2 years ago

Sorry that I dropped this for a bit. I was able to get the RTK data to transmit and receive correctly over the radios as expected. I did factory reset the radios out of precaution just in case I had modified any settings.

nseidle commented 2 years ago

Awesome! Thanks for reporting back. Glad to hear it's working.