Allow assisted start via cellular or WiFi

[nseidle]

From the review by customer #24286.

There's not an obviously way to "hot start" the unit at a known location,

We have the ability to do a very fast assisted start using the u-blox AssistNow system. We just need the ability to push the acquired data to the unit. This can be done over cellular or WiFi. The trick will be the app on the phone. Perhaps we can ask SW Maps to integrate the feature someday.

[gdt]

Is it possible to have an AssistNow client over wifi, similar to how it gets NTRIP?

[nseidle]

Yep - AssistNow over WiFi is very straightforward. My concern is getting lock in the field. Perhaps we require use to run WiFi hotspot?

[gdt]

Require is too strong, but I would say that any feature you can add, that's reasonable, to help is progress, and people can choose a system configuration based on what works. If AssistNow can easily work over wifi, without messing up the RAM budget, then it seems good to add it, even though there will be some people that won't be helped.

The other path is something else fetching, and for that the important thing is to document what the interface is. If it's the case that AssistNow data can be fetched, and then sent over Bluetooth SPP, and this will just be fed to the F9P, and then one could start sending RTCM3, then it would be good to just say that, and various programs one runs on phones etc. could add that as a feature.

Personally, I'm ok with the wifi approach as that's necessary to use something like QField or Vespucci, as I try very hard to avoid non-Free software as someting I don't have any long-term ability to ensure access to or to improve.

Also, I'm not sure how important this truly is. The F9P gets ephemeris pretty quickly with a good sky view. And without a good sky view, RTK is iffy. So I view this as about quick autonomous position from poweron, not about RTK, and while it's always better that things work better, it seems to be for a use case that's a bit off the main path. I suppose it would be nice to have RTK lock in 15s rather than 75, though.

[tonycanike]

I also am not sure how important this really is either. I'm only powering on once or twice per day. Is there a reason or use case (besides testing RCs 😃 ) that requires power cycling frequently?

Would this speed up a base surveying itself in?

My use case would probably be loading the ephemerides at the office where I have internet, powering off, and powering on in the field where I don't have internet. But I read a comment in the library readme that led me to believe it must be online to work.

While this could speed up the first RTK fixed solution, I assume this would not speed up subsequent determination of RTK fixed solutions, as I rarely lose an autonomous solution and the ZED probably caches the ephemerides anyway.

Agreed about the RAM budget point. In reading comments on the other issues, I get the impression that we are already pushing the RAM and CPU budget. Last I checked the log corruption issue hasn't really been totally solved. I had to buy a different unit to do my static collection. (It's collection is rock solid and OPUS is very happy with the data.) But I still have two Facets and I'd like to be able to reliably use all three units to do simultaneous static collecting.

[gdt]

My impression is that the SparkFun F9P units keep standby power to the F9P and thus they don't lose ephemeris. Another big question is what data is sent to AssistNow. I would assume it is just "send me all ephemeris data" because the point is that you don't know where you are.

For base survey in, this could speed up the time to start getting high-quality fixes from about a minute to seconds. But that is really not a big deal IMHO, compared to the time it takes to set up a tripod over a mark.

As for RTK and speedup, to get an RTK fix you need 2 things. One is that to use a satellite you need ephemeris for it. Then, for each such satellite you have RTCM3 data for a number of epochs (which could have been arriving while you don't have a position yet, if your source sends it!), and your own, and you can solve for the integer ambiguities, not assuming that the positions are the same (the K part). So all this is going to do is get you ephemeris faster, but if a satellite is going to be usable for RTK it will load ephemeris from the on-air signal very quickly, probably a bit over 30s.

So all in all I would vote 'defer' for firmware changes, and suggest that people that think they need this experiment with a laptop providing the data over USB or SPP and report back with some data instead of (informed I hope) conjecture.

[nseidle]

Thanks @gdt and @tonycanike! Your thoughts are greatly appreciated.

I'm going to close this as it's a lot of work for a few seconds of lock time savings, maybe. And it has a monthly subscription that adds to the diminishing returns.

My impression is that the SparkFun F9P units keep standby power to the F9P and thus they don't lose ephemeris.

Yes, we keep backup power applied to the ZED-F9P so that it can warm start as quickly as possible.

Would this speed up a base surveying itself in?

Generally, maybe? Survey-in requires a HPA of less than 1m before it starts (a SparkFun applied requirement), then 60s of wait (u-blox recommended time). So if your unit has been on for more than a minute or two during site setup, I suspect its HPA would be better than 1.0m, and the survey in would start immediately. An assisted start would remove the couple minute initial wait, but the 60s survey-in is generally a requirement and the limiter in this case.