Feature request: allow ubx raw on base, while receiving RTCM antenna location on correction

[rtklibexplorer]

Feature request: allow ubx raw on base, while receiving RTCM antenna location on correction

[ccmsi]

Made my own...

[krisgry]

And of course you acknowledge the great work by rtklibexplorer/tomojitakasu, by submitting a pull request? :) @ccmsi

[DavidKelleySCSC]

A bit confused, help me understand. You want a single data stream with ubx binary message content and the occasional RTCM3.x 1005/1006 message inserted with a precise ECEF location? Would NMEA-183 sentences also be present? If the overall goal here to use ubx binary for observations why not just send MSM messages? Different message types in the same stream can be harder for other to parse, and most commercial product offerings cannot do it, just FYI.

[ccmsi]

@Not at all great work, evil hack at best.

https://github.com/navdata-net/meta-navdatanet/blob/rocko/recipes-gnss/rtklibexplorer/files/navdatanet.patch

The idea being that base delivers raw data, which rtklib(explorer) can make the most of, not being affected by any potential omissions by converting through str2str and the lower bandwidth needed on connection 2 / base. As on navdata.net basestations are not predefined, communicating their learned position (ant2-pos) is still needed which seems most appropriate through RTCM 1006. As navdata.net doesnt use channel 3 otherwise, in this case theres no need for an extra socket so was able to reuse that. Even better, allows to inject location updates / changing -p parameters, without interrupting the the data stream.

It seems to work as intended, but I would sure be happy for any and all recommendations for the project i'm working on: http://docs.navdata.net

Bottomline, the intention is to allow for unexperienced individuals to set up basestations at hobby cost that hook themselves up into a cooperative, self organising network that make them learn their correct position over time. Then these shall become usable as reference stations for general public.

I'd be happy to make it a pull request, kind of thinking some refinement would be adequate beforehand.
Let me know your thoughts.

Current dev image for raspberry (connected to M8T) can be found at http://ipk.navdata.net/rocko/navdatanet-station-raspberrypi3-64.rpi-sdimg for those interested. root password empty, so dont give it public IP. Statistics generated on builtin webserver.

[ccmsi]

Wanted to check back to for clarification if such is sth that would actually be considered useful/reasonable to merge or rather not/outside of interest for rtklib/explorer.

[DavidKelleySCSC]

I am not sure if my "imho" thoughts matter here, but my knee jerk reply is to ask again why anyone who could create similar RTCM3 MSM messages would want that? With MSM you get the all important Doppler that is lacking in 1004/12. Looking at a few folks sending raw uBlox over our machines, it is also always bandwidth pig. I think for many people that might want to use it, str2str is a good solution until the Caster just converts it for you. Nothing here suggests there is ever a need/value to "go back" to the raw uBlox in what you describe, right?

Speaking only for myself (and not for my employer's SNIP NTRIP Caster which does a number of these stream combining things - but we charge for it) it may be a long reach "for (in)unexperienced individuals" to correctly understand the relationships in the messages. If they want to send a base station stream to a free community caster (regardless of format), there are things like RTK2go.com (ours) or YouCORS.com or a few others that have sprouted up that all offer such abilities on dependable platforms.

Send the request to tomojitakasu, and ask. I am not sure that mixing two decode calls will not cause a race issue with all the state data. There seems to be a presumption here that there is always a byte to decode in both input buffer streams. It is not clear to me that you can operate on buff[2] just at the same moment that decoderaw() is operating on whatever index happens to be for the same call.

[ccmsi]

My interest to do this in he first place is essentially derived from rtklibexplorer articles indicating that the raw format is both, more complete/accurate and more dense in information per byte, given you configure your receiver to sending only what you are interested in / need in the first place. So assuming those arguments stand, that's the basis on which i would intend to keep that setup for myself.

The decoding i'm not sure, but does not seem to happen in parallel to me. And as i'm only sending 1006, see no potential for collisions if you will either. Indeed, in this simple test hack, there is no safeguards.

To clarify, i don't want to push anything here. I'm just answering above post #3, and if indeed there is an interest in it, i'd also not be shy of trying to improve it somewhat, so the patch isn't as ignorant as it is to the rest of the code. For myself i'm fine with it as it is, cause there's little drama expected applying it to new versions of rtklibexplorer and i know what it is.