I’m back with an update. We have checked, and the 1230 message isn’t empty but contains NULL. Following industry standards, Reach devices internally compensate for all biases; this is why this message contains NULL.
As for the 1033 message, it includes a special identifier—ADVNULLANTENNA (Antenna Descriptor and Serial Number). You can see it in message 1008 as well. Some older receivers may not have an updated antenna register. That’s why we send the Antenna Phase Center (APC) in message 1006, already considering the antenna offset. And use ADVNULLANTENNA in messages 1008/1033.
I’ve also clarified about Emlid Caster. It only transmits data from the base to the rover and does not process any messages. It’s up to the receiver to parse the data. Also, Caster has enough bandwidth to send all the RTCM messages, so message length shouldn’t be the source of the issue.
Hi @inkar.madikyzy !
Yes, I understand that the offset is zero, but it is transmitted as “none” (see the screenshot above).
I think that because of this, receivers like Trimble do not perceive this message. I think if you transmit 0 instead of “none”, then everything will work.
If necessary, I can show the stream that comes from the local Cors system from which all receivers work normally and accept all satellite groups into the solution.
I understand your point. Sending a zero value instead of none might be helpful for your workflow. I’ll note it as a feature request and pass it on to the team. Thank you for bringing it up.
We appreciate your feedback and requests regarding our products. However, this feature to modify the 1230/1033 messages is quite complicated to implement, so I can hardly share any exact plans.
Hello @inkar.madikyzy !
Why do you need to change something at the physical level? The receiver gives out a message 1230, it’s just empty and it seems to me that there is only a problem at the software level. Can’t this be fixed at the firmware level?
OK, thank you! I think this problem must be solved. Do you have any advice on how to get Tribmle and Leica to accept Galileo? Is there any workaround? And one more question. I installed 1.6 frimware on Emlid Reach Rx, and it seems to me that the problem with recording the number of Beidou satellites in CSV has not yet been resolved, am I correct?
As a workaround for the issue with Galileo on Trimble and Leica receivers, we can only suggest checking if these receivers can work with other message types. We’ve noted your feature request to adjust our 1230/1033 messages. However, integrating this feature would require thorough research and testing to see how it will affect other setups.
We appreciate your continued interest and feedback. If there are any changes or updates in the future, we will be sure to let you know.
Thank you! I also noticed that the receiver sees 43-44 SV, but in the caster it gives 30-31. To compare, I changed the caster to rtk2go. The situation is the same there. I wrote to rtk2go support and they responded with the following:
“Well I do see a discrepancy between the SV count in the message header for GPS and the actual content found there. The others seem correct, but this may vary with the number of SVs (and time of day). The might be a side effect of WAAS, am not 100% at sure present (that signal could at one time be sent as WAAS or as GPS). But I also see the ordering of the messages seems wrong, see below. It is normal ( and is required in some parts of RTCM) that GPS is followed by GLO, then the other, all in a given order. Here the message order is backwards from that expected, but they do have the final sync flag set correctly and the sequence number (0…7) is also right. Not sure if MSM allows this ordering, I will have to go look up if that is in fact allowed and ask others. An odd congratulations, that is the first actual RTCM question I had to go lookup in months.
Still looking into this but can say at this time that it will not effect you rover devices, the messages are well formed (correct bytes counts and CRC values) so are being sent out without SNIP dong anything to them. So SNIP is not ‘doing’ anything to the data stream. So the problem might be that Emlid has encoded it (the SV count not the obs messages content) incorrectly with an incorrect count (and perhaps sent the message in the wrong order as well), or it might be that we have an error in our own decoder somewhere.
I will look into the ordering issue and report back. When I look at other Emlid bases they are NOT sending in that order, rather then follow the normal ordering.
And FYI, a navigation filter run on that data looks normal to me, more or less proving that the GPS and GLO data parts are just fine. Send you an email plot from that."
I think this is worth paying attention to and will help you solve this problem.
P.S.For information, I sent this screenshot to rtk2go.
Thanks for sharing the comments from the rt2go team. Did I understand correctly that you’re referring it to the previous issue with the 1230 messages?
I’d also like to point out that on the Status tab, the number of satellites in view shows the total number of satellites that the receiver is tracking. This count can be influenced by your settings:
Enabling or disabling certain GNSS constellations in the GNSS settings.
The elevation mask filters satellites based on their height above the horizon.
The SNR mask excludes satellites with noisy signals.
Good day!
No, I contacted rtk2go with a question regarding the number of satellites. I asked them if there was a limit on the number of satellites on the caster.
This question arose because my base observes 41-43 satellites, and the caster lets through 30-31.
Yes, the number of satellites is affected by the mask settings, snr, etc., but even taking this into account, the caster (it doesn’t matter which caster it is, emlid caster or rtk2go) goes through about 10 satellites less than the base observes.
In my opinion, this problem is indirectly related to the 1230 problem.
Thank you for clarifying. Our development team will look into the difference between the satellites in the Reach Panel and in Caster, and we will let you know the results. Currently, this issue does not seem related to the 1230 message, but we’ll research it further.
We’ve released firmware version 1.7 for Reach RX. This update fixes the issue with the BeiDou satellites, so the number of BeiDou satellites in your exported data should now be correct.
Please update to the latest firmware version and let me know if it resolves the issue. Thanks!
Hola, el mismo problema sucede con el Reach M2, los equipos trimble yalgunos equipos de la marca South, no pueden usar los satelites BeiDou para la solucion fija, solo aceptan GPS y Glonas, quiza puedan actualizar el firware
