Inject 1008 message

[d1ken]

Trimble rovers needs 1008 message. Where the best place for message injection? 1008 message should go after 1005 or 1006 message.

Also, for GLONASS corrections support, 1230 message need corrections (or injection also).

The whole thread with this problems, tests and code (1008 message injection) is here: How to use ZED-F9P as a base station for Trimble

[DavidKelleySCSC]

My advice here is to design the solution be able to send either MT1008 and/or MT1033. Trigger the sending moment to be just after MT1005/1006 (the Base Station Location) arrives on the UART as suggested by d1ken. Do not inject these message(s) elsewhere (such as between the observational messages). In the below, a Novtel device, you will see that these are sent at roughly half the MT1005 rate.

The theory behind why to send the Base Station "antenna description" in these two messages is so that the rover can use that text (presumed to be a product model) to lookup tiny angular carrier bias errors for that ant model and remove them during the navigation filter process. Most often the time the term "NULLANTENNA" is used for this message field when the ant model is not known. And this is what the SC104 stds recommends when no value is present. But as others have observed, an empty message is sufficient to get some Trimble models over their issues. In fact you can put any text string there (up to 31 chars). Here is a view of the two messages and contents using the SNIP NTRIP decoder.

The reason to also send MT1033 is that it then provides a few more hints about the Base Station and firmware that the rover can use to better process the data stream. But doing this is more develpoment effort than sending an empty message frame which seem to be sufficient for the Trimble issue at the moment.

[A further aside, the SNIP Caster can edit and adjust these messages on the fly for the Base Stations it is handling using its PFAT tools. But we also have operators with uBlox F9P Base Station users who have requested we add the ability to inject these station details messages (MT1007/1008/1033 and 1230) when these messages are not present. And we are in fact adding that in our next release. But on the whole, this issue is better solved at the Base Station side with NTRIP Client software such as esp32-xbee. If you need any testing/validation help, let me known. Soapbox off]

[AndrewR-L]

Will injecting MT1008 be an option on rtk2go or is that just for those running their own SNIP Caster?

MT1230 is already available from ZED-F9P / Simplertk2b, even though it outputs data already code-phase aligned.

[d1ken]

I think injecting MT1008 should be done on the NTRIP server or uart input.

MT1230 is already available from ZED-F9P, but Trimble's rovers do not like it. Needs some experiments, to determine the best solution for Trimble.

With MT1008 injected, there will be GPS RTK fix, but ZED-F9P limited to L2C signal, so for L2 corrections there are only 2/3 of all GPS satellites. For GLONASS corrections MT1230 is needed, but Trimble do not work with it from ZED-F9P.

[AndrewR-L]

My apologies I read your link as saying that Trimble 372 worked with the MT1230 from ZED-F9P but I did not appreciate that other models might be different.

This is not a simple thing to do because nebkat's ntrip server is agnostic to what is being served - it is not parsed and it just relays whatever it gets from the ZED-F9P. It is not bothered whether it is RTCM, UBX or whatever.

I do think you need to narrow down first what Trimble does not like about the ZED-F9P MT1230 message and SNIP will be the ideal environment to experiment with that and it will even let you serve the doctored stream to rtk2go or another caster for wider scale testing.

Do the offending Trimble rovers work with other maufacturers bases at all? If so which ones work and which don't? Perhaps there is a pattern which would give a clue to the issue?

If you are close enough to Buckingham to get a fix, I would try the Topcon stream on the Racelogic mountpoint on rtk2go. AFAIK the TPS stuff has little if any code-phase bias on Glonass and the only difference I can see between the MT1230 record on that base and my ZED-F9P base is that the "Aligned" indicator bit is not set (even though the adjustments are nil). If that works maybe all that ZED-F9P needs to do (other than to inject MT1008) would be to lie in the MT1230 message and pretend to be "Unaligned". If not maybe it is best to use MT1033 as @DavidKelleySCSC suggested and pretend to be a legacy base with near zero bias which Trimble would be likely to have in its lookup table (I think you would need to turn off MT1230 in that case to stop it taking precedence).

[nebkat]

I was actually planning on implementing something similar to the PFAT system eventually, so it will be possible one day, but there are a few other things that need to be done before that.

[d1ken]

Ok. What is your suggestion for placing fast and dirty code for message injecting? I am not familiar with FreeRTOS, but I think it can be in uart_task(void *ctx) function. Am I right?

[nebkat]

The uart_inject() function allows you to simulate data being sent to the UART. All you need to do is uart_register_read_handler(... your injector_function ...) (see e.g. https://github.com/nebkat/esp32-xbee/blob/master/main/socket_client.c#L42), detect MT1005 and inject your MT1008.

[DavidKelleySCSC]

Will injecting MT1008 be an option on rtk2go or is that just for those running their own SNIP Caster?

I do not know yet, sorry. In time, when registering a new Base for RTK2go is a fully automated process for the Base Station owner, and we are doing some extra thing to support the uBlox chip set needs, then it make sense to.

I was actually planning on implementing something similar to the PFAT system eventually...

I would urge caution here, first you will have to parse RTCM message details and become very well versed in navigation filters in general, perhaps man years of effort. The eventual plan in our shop is to release generic open source NTRIP Clients and Servers for others to integrate. But things like your work on esp32-xbee go along way to solve that need today.

What is your suggestion for placing fast and dirty code for message injecting?

IMO the code example first referred to by d1ken on the Combine Forum is a good start, it is a very short empty message of perhaps 12 bytes. But it would be better to inject a slightly longer message with the common NULL ANT keyword in it, if needed I can provide the binary byte sequence.

[d1ken]

IMO the code example first referred to by d1ken on the Combine Forum is a good start, it is a very short empty message of perhaps 12 bytes. But it would be better to inject a slightly longer message with the common NULL ANT keyword in it, if needed I can provide the binary byte sequence.

Yes, of course, provide longer message, I will try it. But empty message work good for MT1008.

More problem is MT1230, as I understand right on the Combine Forum, there are no solution for it. It would be very helpfully if you provide some binary byte sequences for MT1230.

[AndrewR-L]

@DavidKelleySCSC re injecting MT1008 - don't worry I was probably a bit premature suggesting that - I did not realise there was a problem with MT1230 also

@d1ken I suspect you may find that ZED-F9P outputs each batch of messages to the UART in one continuous stream which without parsing will make it difficult to insert MT1008 in the middle.

The really Q&D fix probably will put MT1008 at the beginning (ie before MT1005) and your fine tuned MT1230 (or possibly MT1033) at the end (you'd need to turn off MT1230 on the ZED-F9P) but who knows whether Trimble would be precious about the order and if you are not sure you have the right messages it will be hard to troubleshoot.

The problem you have with MT1230 is still a mystery and I do think you need to establish EXACTLY what is wrong with the ZED-F9P version before you even think about coding it into ntrip.

It occurs to me that my local Ordnance Survey station uses a Septentrio base (as do 50+ of the other ones). This is professional kit and like ZED-F9P it outputs aligned (not observed) Glonass data and surely works with Trimble professional stuff. Most of the stations are only available paid for, but in the UK the Case IH RTK+ network uses the OS stations and that surely works with Trimble ag receivers.

A handful of OS stations are publicly available where they are also part of Euref or IGS such as the HERS00GBR0 mountpoint on the euref-ip.net which requires registration but is free (at least until the end of the Brexit transition). You could try that if close enough and/or add its MT1008, MT1033 and MT1230 to a closer stream with SNIP PFAT for testing.

I just checked the HERS00GBR0 MT1230 with SNIP and it looks pretty similar to the ZED-F9P one, the "Aligned" bit is set but it has all 4 fields present L1 C/A, L2 C/A, L1 P and L2P but all 0.00.

Curiously (unless I am misinterpreting the masking bit @DavidKelleySCSC?) the ZED-F9P seems only to have the C/A fields present not the P ones which seems rather odd. Maybe that is why Trimble does not like it?

Also curiously the OS Inverness INVR00GBR0 which also comes from a Septentrio PolarX5 station has its MT1230 indicator bit set to "Unaligned" instead (but with nil offsets obviously) and even curiouser it also streams MT4094 which is a Trimble proprietory one! What is all that about - maybe it is for a reason?

Do you have a ZED-F9P mountpoint on RTK2go (or otherwise public) available to tinker with?

[d1ken]

@AndrewR-L I am from Ukraine and there are no stations near my location, all 50km+.

For now I have Trimble AgGps 542 without RTCM (CMR only). For ZED-F9P rover I need RTCM, RTCM unlock for AgGps cost a lot, much cheaper use another ZED-F9P like base. And if I will have RTCM from ZED-F9P that Trimble can accept, I could sell AgGps :-). Just need some tune.

About MT1230, yes at first I want try inject MT1230 with L1P and L2P fields with zeroes. About MT4094, on the combine forum there was successful tries with Leika base without MT4094. My simpleRTK2B with WiFi NTRIP Master is still on the way. For now I want prepare software for WiFi NTRIP Master.

About parsing, I searched (on Adafruit) ZED-F9P outputs maximum ~2500 bytes (RTCM) in each batch every second. esp32-xbee has uart buffer size 4096 bytes, so I think parsing and injecting is not a problem. Correct me if I wrong.

Another question, for now I have 11 Trimble rovers, with ZED-F9P I am planing much more (20+) in future. Does there are any solution to have more then 16 sockets? Or the only solution is to switch to raspberry pi?

[AndrewR-L]

@d1ken

ZED-F9P outputs maximum ~2500 bytes (RTCM) in each batch every second. esp32-xbee has uart buffer size 4096 bytes

Good point. It will depend on how many satellites but I just checked by base and with MSM7 it is currently averaging only 910bytes/sec (with MSM4 it was around 600bytes/sec - there is a graph of before and after in the issue #5 thread.

Does there are any solution to have more then 16 sockets?

I don't know what the ultimate limits of the hardware/software will be but today you can use the wifi NTRIP master to connect your base to @DavidKelleySCSC's most excellent free global community caster rtk2go and connect almost any number of rovers to that if you have good mobile data locally.

I use rtk2go.com because I don't have a static IP, or even a dynamic one because my ISP uses CGNAT. I have tested the wifi NTRIP master caster with ngrok2 which circumvents CGNAT (but that depends upon having a computer always online which is what the XBee module seeks to avoid).

For now I have Trimble AgGps 542 without RTCM (CMR only).

In theory you can convert a live CMR/CMR+ stream to RTCM with RTKLIB STRSVR but I didn't have much luck when I tried.

And if I will have RTCM from ZED-F9P that Trimble can accept, I could sell AgGps :-).

for now I have 11 Trimble rovers

Are the Rovers now CMR then, if so will you have to pay to unlock the Rovers to work with RTCM base? Better then to sell all the rovers too and use F9P across the board? - that would solve any base-rover compatibility issue!

But what are you feeding with the Rovers? Will it be happy with non-Trimble GNSS? I use Farmnavigator which is designed to work with any brand, but I hear other ag brands are more fussy.

[AndrewR-L]

@DavidKelleySCSC This is probably not the place to ask (but I know you frequent here) how does SNIP calculate the fields in the RTCM3 Message viewer. Particularly the "Doppler" field.

Is this not an RTCM style RangeRate figure as broadcast but rather a RINEX style doppler calculation (-RangeRate/WaveLength)?

The reason I ask is that I notice that the figure I get for F9P is always of the opposite sign compared to Trimble, Leica etc when comparing the same satellites at the same time and I think ublox is in the wrong. It probably wouldn't affect interoperability greatly - maybe just a bit of accuracy?

[nebkat]

Some early and untested code is here https://github.com/nebkat/esp32-rtcm/ for anyone interested.

@DavidKelleySCSC

I would urge caution here, first you will have to parse RTCM message details and become very well versed in navigation filters in general, perhaps man years of effort. The eventual plan in our shop is to release generic open source NTRIP Clients and Servers for others to integrate. But things like your work on esp32-xbee go along way to solve that need today.

I've made a UBX parser before on ESP-IDF so parsing wise RTCM isn't that much of a jump, though I'm really hating how they don't make any effort to bit align the fields. Thankfully MT1005-1008/1033 are all quite reasonable when it comes to this, unlike the MSMs. As for the actual meaning of all the fields, a lot of that is indeed still beyond me, but I'm slowly making progress towards understanding how it all works.

@d1ken

About parsing, I searched (on Adafruit) ZED-F9P outputs maximum ~2500 bytes (RTCM) in each batch every second. esp32-xbee has uart buffer size 4096 bytes, so I think parsing and injecting is not a problem. Correct me if I wrong.

The buffer can actually be made considerably larger, but it is also continuously being emptied so its not the limiting factor in any case (to my knowledge anyway, I have not yet investigated what happens when it is constantly bombarded with data).

If you'd like to get started with it I've included decoders/encoders for all the related messages https://github.com/nebkat/esp32-rtcm/blob/master/rtcm_tools.c#L148

Another question, for now I have 11 Trimble rovers, with ZED-F9P I am planing much more (20+) in future. Does there are any solution to have more then 16 sockets? Or the only solution is to switch to raspberry pi?

Unfortunately yes, that is a limitation of the ESP32. A raspberry pi could do the trick, but unless it's essential that your setup is running super local to the base station itself it would be easiest to simply push to a private instance of SNIP or another caster. At that point though, you might want to just consider connecting the SRTK2B to the PC via USB and skip the ESP32 altogether.

[d1ken]

Yes, I forget that I can use separate caster like rtk2go or install ntripcaster on my OpenWRT router when there will be more than 15 rovers.

I was searched, but I did not find any solution about converting a CMR/CMR+ stream to RTCM.

My rovers are CFX-750, GFX-750 and AgGPS 372, all accept RTCM3. CFX-750 has internal receiver, for now I did not know how to configure it for external receiver. AgGPS 372 talk to nav controller and pro 700 monitor, no way to replace it with zed-f9p (too hard to implement TSIP protocol that acceptable by nav controller and pro 700, maybe sometimes). GFX-750 use nav-900, it is integrated receiver and guidance controller, communication via ethernet, there are no any information about protocol.

[DavidKelleySCSC]

@DavidKelleySCSC This is probably not the place to ask (but I know you frequent here) how does SNIP calculate the fields in the RTCM3 Message viewer. Particularly the "Doppler" field.

It doesn't. The SNIP Caster simply decodes what the other party sends.

Perhaps this is question about the way the that the Caster tool displays things. In the RTCM3 message viewer window several of the observational messages are displayed in a common "compound" layout in where some given data element may not present in one message but is present in another (L2 data is present MT1004 but not in MT1002, Doppler is present in MSM5/6/7 but not in MSM4, etc.) In such cases the data element that is not present is shown as empty with a grey background fill color. This is explained further at this link.

Back to Doppler. And to be of any value the GNSS needs to send it the honest independent measured values, not some 'guess' derived from the expected orbital Doppler or past delta measurements (I have seen 'bad' NTRIP clients try to do this). The rapidly changing Doppler and SNR are vitally important values for use in the Kalman filter weighting when in a moving vehicle. Measured Doppler is new to the MSM messages (types 5,6,7) and was not part of legacy 1004/1012 messages. But proprietary messages (such as uBlox, Hemisphere, others) have included it for a long time. A rapid shift in Doppler usually indicates you have entered a span of multipath. With 10Hz sampling rates you can watch a given SV to platform Doppler value move into and out of such holes. In the RTCM std the Doppler value is called "PhaseRangeRate" (see DF399 and 404) and the units are in scaled m/s (not wavelengths), see/buy the RTCM spec for details.

I also see I need to provide the byte streams for a couple of filler 1008 messages in this thread. Working that out now.

[esuomala]

This U-Blox F9P inverted Doppler sign keeps me confused.

Doppler should be positive as satellite is approaching? Enclosed is a screen capture from RTKNAVI observations from my zero baseline setup (GPS only to make it shorter): Top part is F9P RTCM MSM and below is NetR9 data from BINEX stream. But if I take the data from F9P UBX stream it is not inverted.

So far I have not found any good explanation for this....

[DavidKelleySCSC]

Doppler should be positive as satellite is approaching? Yes, always.

On MT1008 (and 1007 and 1033)
We have just about worked out an improved feature added to the SNIP NTRIP Caster (which is used on RTK2go.com) that will allow 'empty' antenna descriptions to be sent overwriting whatever the device normally sends. [Today you can change the various station description text but not make the entries empty, a use case concept that never occurred to me when we created the PFAT system] It is added now. I am looking for those on this thread who wish to test this out now.

Also, to address the need to create these messages when the sending device does not do so (uCenter and a few others older devices), we have added a simple timer control in our code that will insert the missing messages after the MT1005/1006 message every Nth seconds have elapsed.

Anyone who wishes to provide some raw data to further test this, please contact me. We can set it up on RTK2go.com or on one of our private machines.

[DavidKelleySCSC]

BUMP

Anyone who wishes to provide some raw data to further test this, please contact me. We can set it up on RTK2go.com or on one of our private machines.

This turned out to be a bit bigger in terms of scope that I has estimated. We have now implemented a simple way to inject user created Mt1007/1008/1033 at a user selected rate in any data stream. And you can edit whatever text content there you wish. That will be released in the SNIP Beta channel this week for those that want early access. That should fully solve the issue that came up here for using uBlox as a Base with Trimble rovers, if you are using SNIP as your NTRIP Caster.

But the interesting parts (IMO) was that while Trimble devices seem happy with an empty string, or the strings "ADVNULLANTENNA" or "ADVNULLANTENNA NONE" there are quite a lot of other GNSS devices and tool processing paths that want very specific text here with very specific strings and capitalization. This is normally only an issue for those that need very precise corrections and wish to model the error sources down at the mm level. For example the ant description string "ACCG5ANT_42AT1" (which means an Antcom G5ANT_42AT1 model antenna is being used), cannot be used if entered as "AccG5ANT_42AT1" as the capitalization difference causes problems.

So what we have done on SNIP is now add about 600 predefined ant description strings for the operator to select from. This should reduce the chances of small spelling issues causing problems, and one can still enter free text. We more or less took the current IGS list of calibrated high grade antennas (IGS14.atx and its naming) and associated model numbers. And if we see a string that is a 'near miss' that is pointed out to the operator in reports. I stress again; at least 95% of the world is quite happy with the ADVNULLANTENNA keyword being used here.

FYI the "NONE" found in these strings refers to the radome used and hence a phase delay attributed to that. It is not clear (to me at least) when the NONE keyword makes any difference in various tools.

[d1ken]

Since we found ZED-F9P firmware has defects in calculations: -no MT1008 -wrong (for industrial grade receivers) MT1230 -no PCO and PCV handling for antenna (and maybe satellites) -some problem with Doppler I think all of them can be corrected on the fly by ESP32. So there not enough to just inject message, but there should be some pipelining or queue for processing (recalculation and editing).

[AndrewR-L]

Sorry I have not been on here for some while. I have been busy farming (which was the purpose of the RTK anyway).

@d1ken. Thank you. Very useful to have a list of inter-operability issues to focus attention. And relevant too considering what a good job Trimble have done locking you into their brand (eg by integrating receiver and guidance or using Trimble Standard Interface Protocol).

@DavidKelleySCSC I see that you have been doing much good work re massaging the RTCM stream to fix interoperability, I've not yet caught up with how that is going, but I have no Trimble kit so cannot verify the effectiveness. The neighbours are Topcon and Navcom/Deere.

I think it is useful to keep in mind whether we are -

• (a) trying to make the ZED-F9P conform to the RTCM10403.3 minimum standards (which ought to be a temporary requirement because uBlox DO claim to conform to that standard and it is to be hoped that any deficiencies identified would be fixed in future releases); and/or
• (b) trying to add/amend the ZED-F9P regardless of RTCM10403.3 to work better with legacy equipment and/or agricultural equipment which has been nobbled to support only manufacturer specific variations of the standard.

One caveat here – my copy of the RTCM standard is v 3,2 and 2013 vintage (too mean to shell out the $$$ for the latest iteration!) but should by now be reflected in the latest firmware everywhere, but please bear with me if there are more recent enhancements in v3.3 of which I am unaware.

Since we found ZED-F9P firmware has defects in calculations: -no MT1008

RTCM "Service Provider Message Types - Minimum Service Operation" specifies that MT1033 be transmitted For any MSM above level 1 with a fallback to the less detailed MT1008 “to service legacy equipment”. So this is a defect which uBlox ought to rectify.

Q: Do we know if Trimble is happy with the newer MT1033 in place of MT1008?

If not perhaps we should aim to add both as suggested by @DavidKelleySCSC on 12 Feb (above) until such time as uBlox add MT1033.

-wrong (for industrial grade receivers) MT1230

ZED-F9P conforms just as well as industrial receivers do to the official RTCM standard here (as was highlighted by correspondence from uBlox reported in the combine forum)

With MSM (not legacy) messages the RTCM standard gives base stations two options

1. Correct the GLONASS Code-Phase bias internally and set bit DF421 in MT1230 to indicate “aligned”
2. Don’t correct for the bias, clear bit DF421 in MT1230 to say “unaligned”, specify the biases in MT1230 and have the receiver do all the work.

ZED-F9P legitimately adopts the former strategy (as do Topcon and others). Indeed some would say that this is prefererable given how much processing a rover already has to do compared to a base. Not being a new standard it is not obvious (to me) why Trimble does not like it.

In the old days (pre MT1230) legacy receivers used MT1033 to determine the receiver type and look up the bias in a table. The only people that was good for was those selling firmware updates as the table needed regular updates.

I don’t know what is Trimble’s problem, perhaps it doesn’t handle MT1230 correctly and uses the legacy method with a lookup table instead or perhaps it assumes it will only ever talk to Trimble receivers (and it knows their parameters),

So this reinforces the need for MT1033 (which adds receiver information to MT1008). As I suggested above best to pretend to be an “industrial grade” receiver which outputs MT1230 aligned with nil bias like "SEPT POLARX5TR" or unaligned but with nil bias like Topcon "TPS B125". ie something Trimble might reasonably be expected to interperate with. Definitely NOT by copying MT1230 from some receiver which outputs uncorrected biased data – that will make things worse.

-no PCO and PCV handling for antenna (and maybe satellites)

Here again the RTCM gives two options

1. Recommended: Transmit observations corrected for PCO and PCV and indicate that by specifying antenna type ADVNULLANTENNA in MT1033/MT1008. In this approach the base station coordinates effectively become the phase centre coordinates.
2. Permitted: Transmit observations as is and have the receiver attempt to determine at least PCO from an Antenna lookup table.

The latter approach is becoming increasingly deprecated as professional base stations especially public ones are more likely to use individually calibrated PCO/PCV rather than table figures. Indeed much professional kit (eg Trimble BD970) provides the facility for the user to set the base up in either mode.

In my application (tractors) PCV is swamped by other errors but for PCO when operating ZED-F9P as a base surely all you need be aware of is to set its coordinates correctly. That is – if by measurement then measure to the Phase Centre not the ARP, and if by surveying-in from a public base then to adjust the height manually by the PCO of the antenna on the base used.

In practice I calibrated the height of my base by putting a receiver at a point of known height and then adjusted the base until the receiver gave the “right” answer! If I am a few cm out it is not a big issue because I only have one base (so a few mm error will be constant always) and my tractors are stuck on the ground regardless.

As an aside when operating ZED-F9P as a rover if the base stream is not standardised to ADVNULLANTENNA then the height may be a little out, but at least it will be consistently so.

(Other than adding MT1033) is there any adaption needed to the ZED-F9P stream in this context?

I am aware that PCV varies with Satellite elevation but that depends on the receiver antenna. What issue might there be with ZED-F9P and satellite antennas?

-some problem with Doppler

I have it confirmed that there is an error. It seems that historically there has been some confusion because Doppler deals with frequency change (which traditionally is positive as an object approaches and the RINEX standard confirms that) whereas RTCM deals with velocity (rangerate) which is negative when an object is approaching. UBX messages already dealt with Doppler (correctly). Despite the RTCM standard being clear on this point it seems that uBlox forgot about the sign change when creating standard RTCM.

NB Doppler = MINUS (Phase Range Rate) / Wavelength

This seems not to be no.1 priority for the next ZED-F9P firmware upgrade (some pressure may be required). But given that uBlox claim to adhere to the RTCM104203.3 standard this divergence must surely be only temporary and probably not worth the head scratching trying to circumvent in the meanwhile. For the time-being it may be best to stick to MSM4 (which has not got doppler data) unless in an exclusively ZED-F9P setup.

I think all of them can be corrected on the fly by ESP32. So there not enough to just inject message, but there should be some pipelining or queue for processing (recalculation and editing).

Maybe. I think we should concentrate on coding for (b)-type permanent interoperability issues, while lobbying uBlox to correct any (a)-type deviations from the published standard.

Does that seem sensible?

[AndrewR-L]

UPDATE: I have heard from uBlox via Ardusimple that there is an update for the ZED-F9P firmware to make it more compatible with RTCM Standard 10403.3 due June 2020.

What exactly will make the cut won't be known for a few weeks but two deviations from the standard have been noted. (i) The sign of Phase Range Rate. Work around at the moment is to use MSM4 messages which don't include Doppler. (ii) Absence of MT1033. The argument that Section 3 of the RTCM standard “Service Provider Message Type(s)” / “Minimum Service Operation” specifies that MT1033 must be transmitted with MSM4 or MSM7 seems to have been accepted. Although the footnote "Note1: MT1033 is preferred over MT1008. MT1008 is intended to be used to service legacy equipment." confuses me as I am not sure whether it means that you can meet MSO by substituting MT1008 for MT1033 or whether it should be an additional message. I think MT1033 is the most likely outcome from uBlox (and will allow us to indicate with "antenna type" ADVNULLANTENNA that F9P is using PC not ARP coordinates ie PCO=0 and with "receiver type" pretend to be some well-known kit which outputs aligned Glonass in the hope of helping brain-dead receivers which don't process MT1230 properly) but I don't know whether the SNIP testing has indicated that Trimble will be happy with that.

[AndrewR-L]

I just noticed that although uBlox purports that F9P conforms to RTCM 3,3 SNIP auto identifies the streams as RTCM 3.2. I don't know why that is - perhaps it is hard to tell or perhaps something else is amiss?

[nebkat]

I think it makes most sense if Note1 is referring to the "GNSS CODE-differential operation" section further above, where it lists 1008 or 1033 as options. Either way, sounds like it will be corrected.

Side note, I am currently working on a Node.js based NTRIP caster/server/client that I will most likely release as open source. It includes a full RTCM 3.3 decoding/encoding library too, so it will be quite easy to do whatever conversions/additions are necessary.

I just noticed that although uBlox purports that F9P conforms to RTCM 3,3 SNIP auto identifies the streams as RTCM 3.2. I don't know why that is - perhaps it is hard to tell or perhaps something else is amiss?

I presume it is decoding the RTCM messages and setting the version to the minimum level required to support those messages. Only Galileo/Beidou ephemeris and SBAS MSM were added in 3.3, so if neither of those are being sent then it can be a 3.2 stream.

[DavidKelleySCSC]

I presume it is decoding the RTCM messages and setting the version to the minimum level required to support those messages. Only Galileo/Beidou ephemeris and SBAS MSM were added in 3.3, so if neither of those are being sent then it can be a 3.2 stream.

This is in fact the logic used by SNIP to determine the RTCM revision used. [And the new revision 3.3 is not yet officially out yet (about a month to go) SNIP rev 3 (our next release) fully supports it]

[d1ken]

Does somebody tested new firmware? Does they fixed MT1230 and Doppler?

[d1ken]

@nebkat What is current status of your Node.js based NTRIP caster. I am searching now for the caster with Nearest feature.

[nebkat]

@d1ken I will most likely be releasing it in the next week or so, but currently it does not have the NEAR mountpoint feature.

[thomasjetzinger]

Does anybody know if Trimble receivers (e.g. AG-382) works with the new 1.13 firmware?

[d1ken]

@nebkat What is current status of your Node.js based NTRIP caster. I want to write my own Node.js based NTRIP caster with Nearest feature. If you have some code to share it could be very helpful.

[DavidKelleySCSC]

Side note; please don't use our firms trademarks (NEAR, NEARest, and a few others) in this way, that term only has meaning within the context of the SNIP NTRIP Caster.

[nebkat]

@nebkat What is current status of your Node.js based NTRIP caster. I want to write my own Node.js based NTRIP caster with Nearest feature. If you have some code to share it could be very helpful.

Putting the finishing touches on it now, will release tomorrow or Friday.

[nebkat]

@d1ken Here you go :smiley: https://github.com/node-ntrip/caster. Very much an alpha release and will have some major changes coming soon, but still has quite a lot of useful features. Will improve the documentation and provide some more samples tomorrow.

Also of interest will be the RTCMv3 parser https://github.com/node-ntrip/rtcm. To my knowledge it is the only open source parser that supports every single message type, and also happens to be very readable, so I hope some interesting stuff can come from this!