Restart survey-in on powerup

Hi, I’m using the Sirius RTK base with a direct telemetry connection to the rover module. I want to be able to set up the base in any location and it should automatically do the survey-in and start streaming RTCM data once finished. There is one problem however: when I turn off the base module and later turn it on in a new location, it remembers the result of the previous survey-in and doesn’t start a new one. This happens even if I take out the batteries in between. In order to restart the survey-in I have to connect the module to u-center and trigger a cold start. How can I eliminate the need for this step? The u-blox manual mentions that you can drive the RESET_N pin low to trigger a cold start, is there any way to access this pin? Or is there a configuration setting I missed?

Edit: It looks like the state is only kept if the base is off for less than ~45min (with or without batteries). However, this is still way too long to wait if the base was accidentally moved after turning it on or if multiple deployments are done in succession.

Hi there,

I understand you have difficulties using the Sirius BASE RTK autonomously.
Reason why the survey-in doesn’t initiate when the module is powered off and then later powered up using batteries, probably could have lead to an error for not being stored on Battery Backed RAM (BBR).

You may want to go into u-center to add and save this function manually.
“Go to Generation 9 Confirguration View” and then select “Time Mode 3” to add changes to the Survey-In (minimum observation time & position accuracy limit then save the configuration with the RAM, BBR and Flash selected to store the configuration)
This will save the configuration and restart surveying whenever rebooted up with batteries.


[del]
[set]
RAM CFG-TMODE-MODE 1 # write value 1 - SURVEY_IN to item id 20030001 in layer 0
RAM CFG-TMODE-SVIN_MIN_DUR 0x3c # write value 60 0x3c to item id 40030010 in layer 0
RAM CFG-TMODE-SVIN_ACC_LIMIT 0xc350 # write value 50000 0xc350 to item id 40030011 in layer 0
Flash CFG-TMODE-MODE 0 # write value 0 - DISABLED to item id 20030001 in layer 2


I hope this works.

Thank you and have a nice day.

Hi Anthony,

Thanks for the suggestion. The problem indeed seems to be that some state related to survey-in is stored in BBR. Unfortunately your proposed solution doesn’t work.

Here is the relevant part of our current configuration:

[del]
[set]
Flash CFG-TMODE-MODE 1                # Survey-in mode enabled
Flash CFG-TMODE-SVIN_MIN_DUR 120      # survey-in min duration 120s
Flash CFG-TMODE-SVIN_ACC_LIMIT 50000  # survey-in max uncertainty 5m

Using the values you suggested makes the module do a survey once while it’s on, and then when you reboot it goes into the default rover mode (where we want it to do a new survey). As far as I can tell, writing values to RAM or BBR can’t possibly solve our problem, because those values get overwritten from the flash once the module powers off and the BBR expires. We want to configure the module only once and then never have to update any parameters again. But this is not possible as long as the survey-in state is stored in BBR and only gets reset when you change the survey-in parameters or the BBR expires.

Is there any way to disable the BBR entirely? Or any other solution you can think of?

Thanks

Hi Daniel,

It is possible to save the configuration after a warm start but a cold start resets all the configuration to the default values. In terms of cold start, it is unclear how we can fulfill to perform a survey-in without u-center. It is required to execute some hardware/software edits to try to stagnate the positioning and perform a survey-in.
I have added a link that demonstrates an effort to drive the RESET_N pin that corresponds to the BBR.
https://portal.u-blox.com/s/question/0D52p00008HKCKrCAP/unable-to-keep-rtc-and-satellite-information-alive-in-bbr-by-vbckp-in-camm8q
You can also check this: https://portal.u-blox.com/s/question/0D52p00008HKCHfCAP/configuration-backup-in-bbr-anything-to-consider
I will look into this test too when possible, hope this helps.

Best Regards,

Hi Anthony,

Is it possible to access the RESET_N pin somewhere on the Sirius RTK base PCB? Then we could add a switch to reset the module. Or can we simply remove the battery that powers the BBR? I don’t know where that battery is located.

Thanks

Hello Daniel,

I am using Drotek module ZED-F9P in Base/Rover configuration to perform GPS-RTK experimentation for research purpose.
I am encountering same issue you are mentionning.
When I power off the GPS Base, and restart it at another location shortly after: even in Survey IN, it performs a Hot start and won’t update the location fix unless I do a manual reset to cold start using U-Center.
As I want the base to operate only connected to a battery and not to a PC with U-Center, I am wondering if you have solved or work around the issue?

did you used HW solution reseting the RESET_N Pin on the U-blox Module?

Thanks,

Hello Patrick,

No we did not find a good solution to this problem. It doesn’t seem like the reset pin is accessible on the Drotek module. We will probably add a microcontroller to the base station to deal with the issue eventually, but it’s very annoying that there is no simple solution to such a basic problem.

1 Like

Hello Daniel,

Thanks for your feedback.
I have opened the cover on my module, unfortunately, I can confirm that the module’s pins are not accessible at all. the pins are on bottom side of the module. and I don’t see even a trace we could use that goes to that Pin, unless we open the U-Blox cover.
Note that I can see the Battery that saves the BBR data. We could think of a circuit that disconnects the battery shortly at startup.

If I summarize the solutions or work around:

  • control the RESET_N pin at startup: need a specific layout to access the PIN on the Drotek module.
  • issue a coldstart with a microcontroller connected to the USB port at startup to transfer all relevant command to place the drotek Base module in a known and controlled state.
  • no Flash or BBR based configuration can overide GPS Base factory startup sequence
1 Like

Hello, I’m using the F9P with my own driver and software. I’ve had the same problem getting SVIN to restart.

I’ve found that there are two reliable ways to do this. First, to change one of the settings, e.g., change the survey-in time by one second. The other is to disable tmode, then re-enable it. I noticed that if I did this in u-centre, it worked every time, but in my own software it works intermittently. The key seems to have been the length of delay between disabling and re-enabling. When you do it manually, in u-centre, there’s a natural delay. The driver has to be told to wait explicitly. One second does it. At this point I don’t know what the specific interval should be, just that it now works. I do this in the RAM layer without a reset or power-down and it works fine.

Hope this helps someone.

1 Like

We managed to find a workaround for this issue without adding a microcontroller. If you remove the EMF shield covering the u-blox module (the top just snaps on), you will find a small battery which powers the BBR. Removing it completely didn’t work for us (the module didn’t start at all), but replacing it with a 33uF capacitor worked. This is only enough to keep the BBR powered for ~1s after the main power is turned off, which means we get a cold start every time we power the base as we wanted.