[HN Gopher] Improved Galileo Time to First Fix
       ___________________________________________________________________
        
       Improved Galileo Time to First Fix
        
       Author : todsacerdoti
       Score  : 65 points
       Date   : 2022-09-07 13:22 UTC (9 hours ago)
        
 (HTM) web link (berthub.eu)
 (TXT) w3m dump (berthub.eu)
        
       | tasqa wrote:
       | I think these calculations are done in some specific part of a
       | SoC (at least on mobile phones). So do you need new hardware to
       | take advantage of these upgrades?
        
         | jsmith45 wrote:
         | That probably varies. I'm not actually even slightly familiar
         | with the design of these chips. At one extreme, I know you can
         | have a software defined radio (possibly with limited range) and
         | do everything in software. But in practice there will be
         | dedicated hardware for at some things, like acquisition
         | hardware that tries to lock onto a specific satellites prng
         | encoding.
         | 
         | I'm not sure if the position calculations themselves usually
         | use specialized hardware, but I would expect that processing of
         | most data frames is handled by a small embedded processor,
         | simply for flexibility. If the position calculations are done
         | in software, then updating to use this data is probably
         | possible in some designs with just a firmware update. Even if
         | the position calculations are done in hardware, I'd bet the
         | parameters are passed in from the software on the embedded
         | processor, so it sounds like the conversion to the traditional
         | parameter could allow that to be reused, as long as the design
         | does not try to reuse these parameters in other ways which
         | could cause trouble. If it does then the new limited Ephemeris
         | data cannot be used, but the parity data might still be usable
         | to improve time to first fix.
         | 
         | But all of this relies on the SOC supporting upgradable
         | firmware for the embedded processor, that the SOC maker
         | actually develop and provide that new firmware, and that the
         | device manufacturer decides to incorporate that firmware update
         | into a device update.
        
       | addaon wrote:
       | This fault condition --- a 30 second message where the client
       | regularly needs to wait for a complete retransmit due to
       | temporally-local interference --- seems like the perfect case for
       | fountain codes.
        
         | ahubert wrote:
         | hmm not seeing it yet - this is very low bandwidth but fixed
         | rate stuff, where the messages being broadcast also change from
         | time to time. But I may not be understanding fountain codes
         | well enough - they sure seem interesting!
        
       | johnklos wrote:
       | I love a good technical explanation like this. I don't plan to
       | implement a Galileo position calculator any time soon, but it's
       | still fascinating all the same to know what's going on behind the
       | scenes.
        
         | ahubert wrote:
         | Let me know if you ever plan to, I'm ready to help :-) (OP)
        
       | netsharc wrote:
       | > [...] if an important message is missed or too garbled, we have
       | to wait 30 seconds for the next transmission.
       | 
       | > For this reason, most phones attempt to download the orbit and
       | clock details from the cloud.
       | 
       | Pun intended?
        
         | ahubert wrote:
         | No :-)
        
       | WJW wrote:
       | This takes me back to when I was still in the (Dutch) navy, there
       | was a project to replace the submarines and as part of the
       | upgrade they were planning to replace the old periscope mast with
       | an upgraded optronic system. This was basically a webcam on a
       | pedestal that would quickly go above water, take a 360 degree
       | photograph and then dip below the waves again. This would take
       | mere seconds, minimizing the time that the submarine would be
       | visible. The data could then be analyzed at length while safely
       | underwater.
       | 
       | However, the newer system was so much faster that the GPS antenna
       | mounted on the periscope mast could not get a fix in time. If
       | they wanted a position fix as well as a look around, they would
       | need to leave the mast up much longer. (Submarine navigation is
       | much more difficult than navigation for surface vessels,
       | basically all INS. Getting a GPS fix every now and then is really
       | helpful) By the time I left, it was still an open research
       | question on how they would go about it. IIRC, one of the ideas
       | was to simply collect a wide spectrum recording of whatever could
       | be received and do all the analysis later. This would result in a
       | position fix somewhere in the past, which would then be combined
       | with the data from inertial navigation sensors to get an
       | approximate current location. No idea if that system is what they
       | eventually went with though.
        
         | BuildTheRobots wrote:
         | The idea of doing a spectrum recording and having something
         | else process it in non-real time was actually used for Mobile
         | Assisted GPS used to locate mobile phone users ringing
         | emergency services.
         | 
         | Iirc it was a stopgap measure to improve cell tower location
         | without requiring handsets smart enough to process GPS or that
         | didn't have enough time to get a fix. It's briefly mentioned in
         | Wikipedia though details are scant:
         | https://en.m.wikipedia.org/wiki/Radio_resource_location_serv...
        
       | MayeulC wrote:
       | Nice explanation, thank you. I hope this will surface in oss libs
       | soon.
       | 
       | > the Galileo satellites themselves provide properly equipped
       | receivers (not your phone) with near-realtime updates that can be
       | used to achieve very good accuracy.
       | 
       | I have wondered about that. What stops a mobile phone from
       | benefiting from that and RTK?
        
         | ahubert wrote:
         | Hi! So a phone could well benefit from RTK, but this is a local
         | signal, so you have to pick up something that is relevant for
         | your location. Meanwhile, the High Accuracy Service broadcasts
         | realtime corrections, but it does so on a frequency band that
         | is not supported by phone handsets. Also, the RF conditions in
         | most urban environments are such that I'm not sure such
         | corrections would be received well enough to matter in most
         | cases. Phones are moving to dual frequency chipsets which will
         | also improve accuracy without further help. Hope this helps!
        
           | MayeulC wrote:
           | Thanks, it being another frequency makes it clear :)
           | 
           | Getting access to local RTK data isn't much of an issue with
           | projects like https://centipede.fr/ and you can always build
           | your own base staion. I was told multiple times that it
           | couldn't work for phones, without elaborating.
        
       ___________________________________________________________________
       (page generated 2022-09-07 23:02 UTC)