I’m trying to set the RTK Torch to log data in UBX format to send it later to OPUS and CSRS, however, after setting my messages I noticed there is no option to enable: UBX_RXM_RAWX or UBX_RTCM_1230 for example.
I used to do this using an RTK Facet head but its faulty now and we are currently waiting for the spares to repair it, my question is, is it possible to log data with the torch? I’m using SW Maps on an android tablet to log the data as the torch doesn’t have a SD card slot built in.
When I log data and try to convert to RINEX on emlid studio software it gave me an error, I reached emlid customer service and they said the UBX file I sent its binary but it contains the NMEA messages and that’s the reason I can’t convert to RINEX
UBX is a proprietary message format only found on u-blox modules. The Torch uses the UM980. You will need to enable a handful of RTCM messages and then go through a post processing step to obtain RINEX using RTKLIB.
This is very similar to the LG290P (also not u-blox) issue discussed here. Obviously the commands are wholly different, but the Torch currently supports the enabling of a whole host of RTCM messages. I just don’t know which ones to tell you to enable to get to a PPP CSRS solution.
To make this easier, we really need a ‘Surveying Defaults’ akin to the original RTK line that enabled the u-blox RAWX and SFRBX messages, but for the Torch and Postcard. I’ve created an issue here to add that feature but it may be a good bit before we can get there.
Since SW Maps has a feature to create & save UBX files, this might not take much.
It’s my understanding that the app can generate these even for non U-Blox chips.
Anyone know which RTCM messages are the minimum required for SW Maps to generate UBX?
IDK, and unfortunately I don’t have my Torch with me, or any of my tablets that I’ve previously used the “Log to File” option in SW Maps.
This Post suggests the user was successful (although with a F9P).
I’m still guessing that a U-Blox chipset isn’t a requirement for SW Maps to generate the file…but that’s a guess
Now I only logged for ~30 seconds but I think this works. I’ll start building out that logging option. It’s pretty tedious to select all the RTCM messages.
You pick the COM port and rate you want. OBSVMB is the important one. If you want a Navigation file the xxxEPHB commands will give you that. The (NMEA) GGA sentence might be needed if you want an approximate position in the RINEX file. Again only the OBSVMB data is necessary for OPUS/AUSPOS/CSRS processing.
Of course the Output GNSS data to USB is disabled, but even when enabled i just see the whole strings.
I downloaded the UPrecise software from the unicore communications website but it won’t let you configure the receiver through it, however it’s just plug and play to visualize data and upgrade the torch which is nice, im currently logging data with the RTCM messages suggested on to try with the RTKCONV.
Is there any workflow update on this? my Facet got drown and I need to log raw data to send to OPUS, I only have my torch alive, do I have to buy something else? Also i dont know if there is any update on the NGS listing for the torch?
If I read this right you are trying to effectively log RINEX data with the RTK Torch? I have had good success with it and have successfully sent files to NGS with the correct antenna selection. You only need a phone or tablet plus a PC to convert the file. I am overseas at the moment but can provide detailed instructions when I return home in a week.
Hey, Tha k you for checking this out, yes I was able to do it properly, is was easier than I thought, I captured the data with my laptop and then convert it to RTCM using RTKlib and submitted to opus, all came clear!!
Good to hear. It also took me some time to figure it out. I logged using SW Maps logging function and copied to PC. I have been working on summit elevations an a laptop gets clumsy.
FYI PyGPSClient (via its underlying parser pyunigps) is also capable of parsing Unicore binary messages (which include observation, ephemerides, time and ionospheric correction data) and configuring receivers like the UM960 and UM980 via its “TTY” (ASCII text) configuration facility.
