I totally understand that you test all stable releases vigorously but there are always some outliers that cannot be tested for. In those cases you have left folks high and dry without the ability to roll firmware back to a previous state that worked for them. There may also be issues in stable firmware that you had not found that will pretty much ground the units until you release a fix. Seems quite silly as this could alleviate some issues but emlid seems quite reluctant to listen or care.
I was lead to believe that SSH root access has been taken away after a recent firmware upgrade?
The radio can broadcast on one of many frequencies. In many countries, only a portion of those available frequencies are allowed to be used without obtaining a license. So, depending on your geographical location, the useable range of frequencies will be different.
e.g. some countries are more permissive at the 868Mhz end of the range and some are more permissive at the 915Mhz end of the range.
I propose to redraft the tab āBase modeā. If the receiver is not the base, i.e. āOFFā, it should not be in this tab active āBase coordinatesā and āRTCM messagesā.
Thanks for this update.
I have done a confirmatory test session. I still expect such confirmation from users who also reported this to me.
I attach the survey report. Unfortunately only in Polish, because this external controller has no foreign version.
greetings 2020-04-16_21-19-18.zip (4.6 KB)
Session made with Reach RTK module, RTN method, data stream: RTN3G_VRS_RTCM32 (GPS + GLO + GAL)
I also did an additional test for checking of cycle-slip detection and repair in the new version 2.22.4. For this purpose, at the same point as previously, I briefly interrupted the reception of satellites by covering the antenna by hand. This time, the solution was always āfixedā, it gave the same result. However, with a longer break reinitialization, it is sometimes frozen. It can be seen here:
raport_test_17_04_2020.zip (4.5 KB)
From this conclusion that in this version 2.22.4 this problem has probably been optimally solved.
However, there are still cases, already signaled in several threads, freezing the process of initialization and re-initialization. This occurs when the solution āfloatā remains in a place like this:
Here in this test it is RTK method to the remote 20km reference station so such freezing is justified. Manual parameter change definitely speeds up the re-initialization, for example, a minor change, e.g. in RTK Settings elevation mask by one degree or GLONASS AR mode. I guess this can be done programmatically. This problem did not occur in earlier versions before reflashing so it may be worth returning to that initialization algorithm for one-frequency receivers. Maybe this should to be worked out in the next version.
The test concerns the Reach RTK module.
It can be seen that after the discussion EMLID team left in this new version 2.22.4 active frames for āBase coordinatesā and selection of āRTCM3 messagesā with inactive base mode. This causes the user to doubt whether it may conflict with the measuring procedure if he only works with the receiver as a rover with NTRIP. Please, dispel these doubts.
