Yeah. Glonass (the Russian system) had an 11-hour outage back in 2014 because they uploaded an incorrect ephemeris to all their satellites and could only correct them when they flew over Russia. I think that was the worst GNSS outage of the modern era until this one.
Galileo has not declared Full Operational Capability (scheduled for 2020), it's still in the Initial Services stage. It's a bit like complaining that a beta has bugs.
The testing phase ended in 2016 - Galileo is a live GNSS network intended for actual use in navigation. The reason they haven't declared Full Operational Capacity is that they still haven't managed to deploy a full constellation of satellites. All of the official announcements and navigation messages from the satellites say that it's meant to be providing actual service, just with slightly degraded accuracy due to the missing satellites.
Not only that, the EU's controversial eCall initiative, which requires cars that go on the market after April 2018 to automatically call the emergency services with their locations and a live mic to the interior if they detect a crash, mandates the use of Galileo for positioning. Manufacturers can (anbd probably will) use other GNSS systems in parallel, but Galileo is the only one that's guaranteed to be supported by cars. This is for a system whose life-saving benefits are supposedly so important as to outweigh the privacy issues.
In 2016 they did announce "the transition from a test system to one that is operational" [1] so I can understand why some people might find the distinction confusing.
It was just a few weeks ago that there was a US midwest and eastern GPS timing precision error that prevented commercial jet's ADS-B from accepting it and causing them to give up throwing errors. ref: https://hackaday.com/2019/06/09/gps-and-ads-b-problems-cause...
This ended up not being a problem with the GPS system at all -- it was actually a certain brand of receivers not dealing correctly with leap seconds[1] -- or, specifically, that it's been a while since the last leap second, which caused one of the GPS parameters (basically 'how long since/until a leap second' to roll over, which is not normally a problem, but thanks to a receiver bug, it was, on these specific receivers. This was covered in some detail on the LEAPSECS mailing list.[2]
That doesn't appear to be an outage. It appears to be equipment that requires GPS to have a particular level of precision, which may or may not have been chosen cleverly enough for times when GPS isn't working perfectly.
That's a pretty interesting set of data. Even one minute outages of satellites seem to be logged, even though that's probably pretty normal for receivers to have to deal with for other reasons.
Who are the consumers of outage information like this? Or is it simply informational?
There are networks of precise GPS receivers in known locations creating permanent reference networks [1] [2] [3]. High precision applications can gather 'observables' for a few hours then 'post-process' them, comparing them to the data from the permanent reference network, to achieve sub-centimetre accuracy.
Now, obviously these networks will have spotted the outage on their own if they're any good, but extra reports amount to saying "Yep, we saw that too"
GPS is also fairly old and run in the aerospace-and-military tradition where every outage requires an announcement made in NOTICES IN ALL CAPS because that's what pilots did in 1950 :)
I'm surprised there are quite so many single satellite outages, and no whole-system outages.
What causes satellites to suffer single satellite unplanned outages? Uploading bad software? Bad data? Wrong commands for orbit adjustment?
One would think that after the 20th time these mistakes had been made, automated tests would be in place to prevent them happening again.
Yet it's impressive no whole-network outage has happened. Presumably after uploading data/commands to one satellite, it gets uploaded to the rest. Yet there has never been a time that everything looked okay till after it was deployed worldwide?
The majority of those outages are listed as single-minute, (or as planned downtime).
And there are 31 GPS satellites in orbit when global coverage is possible with only 24.
This, combined with a fully redundant control segment on the ground and a satellite 'autonav' feature that lets them run (with degraded accuracy) for up to 60 days without the control segment provides reasonably good protection against whole-system outages.
There's a bunch of maintenance stuff that happens regularly that's on that list... FCSTDV (stationkeepng burns), FCSTMX (scheduled maintenance, like switching to a different atomic clock or the like), that sort of thing.
There's a lot of recent UNUNOREF on the agi.com link in this thread's grandparent, which is basically "it broke and came back before we could send out a note". If you look closely at that list, though, you'll see that almost all of the recent events are a single satellite -- PRN18. I have no idea what's wrong with it (and AFAIK there's no way for the public to get the details), but it's been going unhealthy for ~2 minutes at a time for months now.
(I'm guessing they keep it live because either don't have another satellite positioned so they can put it into that slot easily, or because they don't consider whatever is wrong with it to be a huge problem.)
The author mentions how they're not going to talk about rumors several times over the course of the article. I'd love to hear what the rumor mill is saying about the possible causes of the outage.
I'm no expert but according to this site, linked in the article, it appears the system has started to come back online and that the issue was limited to the ephemerides: http://www.navsas.eu/node/611
It is a massive oversight that the satellites don't mark their own data as bad if not commanded to from earth.
There are lots of reasons ground stations could go offline, and having the satellites broadcast no data is far far better than broadcasting incorrect data.
1-bit recording is in fact a common thing for very noisy signals. You're actually aggressively over-sampling and using correlations over many samples (in time) to get the signal out from under the noise. I've only glanced over it, but this looks like a fun related article, but driving the opposite way (oversampling to get more effective bits) https://thecavepearlproject.org/2017/02/27/enhancing-arduino...
> Also I’m curious about the 1-bit recording. Is that a thing?
Yes. This homemade GPS receiver uses a simple comparator (1 bit) to sample the signal (after amplification to get the noise floor over the decision threshold).
> Also I’m curious about the 1-bit recording. Is that a thing?
I'm no expert, but sounds like what you'd do with sigma delta modulation[1]. Basically you use a 1-bit ADC (a simple threshold comparator), but sample at a rate much above the Nyquist rate. The idea is that for a given value of the source signal, the noise inherit in the recorded signal will make some samples register as 0 while others 1.
You then basically average samples to extract the signal you're after.
I have had access to a limesdr, bladerf, etc. They are finicky. They're great tools, but it took me a long time to go from toy examples to doing useful things with them.
Putting together a gnuradio pipeline to play radio stations or whatever signals you can find is rewarding. Especially when you can get the waterfall spectrogram working
I didn't do anything useful before I had to for work, and it took 10x as long as it should have. I'd suggest just taking some known working examples for fm radio, garage door openers, etc and working through them. It'll be painful, but with enough time and effort it'll happen. And it's sort of like makefile debugging-- the first ten times you have to do it it's excruciating, but after that it turns into just another task you know how to do.
FWIW there are frontend plugins for LimeSDR that will let it work with SDR# and other standard listening applications. Gnuradio can be extremely frustrating for just basic tinkering.
The software documentation for people new to it is awful. The hardware is probably great, but I've had such a hard time with mine.
It's not newbie friendly at all, and the people in HAM and SDRs don't know how to teach. It's all jargon that they never define or things just like "Oh do XYZ in this software" and that's an entirely non-obvious thing that's entirely undocumented with no tutorials.
A lot of SDR stuff is like you're a person wanting to drive to the store to get some ice cream so you can eat the ice cream. So they give you the blueprints.. to an auto factory. So you can build an auto factory. Which will then build a car. Which you can THEN drive to the store.
Hope there's still ice cream left by the time you get there.
If there's a silver lining, you do learn a lot whether you planned to or not (mostly about how much more other people know than you do).
I first dipped my toes into it with the RTL SDRs back when they were first 'discovered'. I got into listening to local police scanners but got tired of chasing peaks in the spectrum. So I learned a little bit about DSP, wrote a couple of little auto-tuner plugins for one of the more popular SDR applications, built a crude audio pipeline to demodulate the p25, but ultimately had a $1200 PC doing a bad job at being a $200 scanner.
I started to pick it apart more when some genius masochist builds an SDR scanner that does all of the above (including multi-vcos), but then snips out the audio files, tags them with the origin and makes them available for the world to listen via a nice clean web ui. Demoralized and defeated I just moved on to tinker with ADS-B.
I've got a LimeSDR-mini (which is more economical). If you're only interested in RX, you should definitely consider the cheaper RTL-SDR. I'm just starting to learn about SDR, and am far from sending anything. I wish I had gone with an entry-level device first.
I’ve got at least a dozen RTL’s strewn around the place lol. They are easy to use but once you hit some of their limitations you wind up wanting something more
Before they sunk countless billions into this nonsense the promise was EU's tech independence on the US. Well, it turns out that the worst thing you can depend on in the EU is EU itself.
The thing with GNSS is that it is WELL below the noise flow and you need a lot of coding gain to receive it. That on the other hand really reduced the data rate at this you can transmit secondary information such as ephemeris and slowly changing time information. Sending 3 bits for day of week instead of 16 bits or so for a full date makes a real difference for time to the first fix after a cold start.
You clearly haven't read the rest of the article. It's not even especially far down that it's mentioned that the accumulated error for the orbital calculations has resulted in errors for satellite positions into hundreds or thousands of meters after a few days.
They made the time fields short because the information would have no value on timescales larger than that.
Thats what the status bits are for. That they didn't set them to 1 on the full constellation suggests there may have been some trouble they didn't publicize.
The status bit that was set is supposed to mean "working without guarantee" - that is, the satellite may not meet the normal minimum performance level but is still in service. This specific combination of status bits corresponds to a status of "marginal", between full health and actually out of service. In order to actually mark the satellites as fully out of service they'd need to either replace the navigation data with dummy values or upload new navigation data with some additional status bits set.
The whole thing seems a little odd. Even the original 80s GPS satellites could automatically update their ephemeris data with stored predictions for 14 to 60 days after the last contact from the ground segment (with a gradual decrease in the signalled accuracy over time), after which time I believe they would switch to invalid dummy data. The current generation can compute their own ephemeris updates at almost full accuracy for months if the ground segment fails.
I have to wonder how Galileo ended up transmitting such stale data that ground-based recievers ended up mistaking it for next week's data and still marked it as basically valid. That seems like quite an oversight.
How often has GPS, excluding intentional military operations, been unavailable?
Edit: Went looking around and it seem GPS has never suffered an outage. They have had issues with some satellites, even two days ago it seem, but never a true outage. http://navigationservices.agi.com/SatelliteOutageCalendar/GP...
Yeah. Glonass (the Russian system) had an 11-hour outage back in 2014 because they uploaded an incorrect ephemeris to all their satellites and could only correct them when they flew over Russia. I think that was the worst GNSS outage of the modern era until this one.
Galileo has not declared Full Operational Capability (scheduled for 2020), it's still in the Initial Services stage. It's a bit like complaining that a beta has bugs.
The testing phase ended in 2016 - Galileo is a live GNSS network intended for actual use in navigation. The reason they haven't declared Full Operational Capacity is that they still haven't managed to deploy a full constellation of satellites. All of the official announcements and navigation messages from the satellites say that it's meant to be providing actual service, just with slightly degraded accuracy due to the missing satellites.
Not only that, the EU's controversial eCall initiative, which requires cars that go on the market after April 2018 to automatically call the emergency services with their locations and a live mic to the interior if they detect a crash, mandates the use of Galileo for positioning. Manufacturers can (anbd probably will) use other GNSS systems in parallel, but Galileo is the only one that's guaranteed to be supported by cars. This is for a system whose life-saving benefits are supposedly so important as to outweigh the privacy issues.
In 2016 they did announce "the transition from a test system to one that is operational" [1] so I can understand why some people might find the distinction confusing.
[1] http://www.esa.int/Our_Activities/Navigation/Galileo_begins_...
It was just a few weeks ago that there was a US midwest and eastern GPS timing precision error that prevented commercial jet's ADS-B from accepting it and causing them to give up throwing errors. ref: https://hackaday.com/2019/06/09/gps-and-ads-b-problems-cause...
This ended up not being a problem with the GPS system at all -- it was actually a certain brand of receivers not dealing correctly with leap seconds[1] -- or, specifically, that it's been a while since the last leap second, which caused one of the GPS parameters (basically 'how long since/until a leap second' to roll over, which is not normally a problem, but thanks to a receiver bug, it was, on these specific receivers. This was covered in some detail on the LEAPSECS mailing list.[2]
[1] https://www.flyingmag.com/collins-receivers-struck-by-failur...
[2] https://pairlist6.pair.net/pipermail/leapsecs/2019-June/0071...
That doesn't appear to be an outage. It appears to be equipment that requires GPS to have a particular level of precision, which may or may not have been chosen cleverly enough for times when GPS isn't working perfectly.
That's a pretty interesting set of data. Even one minute outages of satellites seem to be logged, even though that's probably pretty normal for receivers to have to deal with for other reasons.
Who are the consumers of outage information like this? Or is it simply informational?
There are networks of precise GPS receivers in known locations creating permanent reference networks [1] [2] [3]. High precision applications can gather 'observables' for a few hours then 'post-process' them, comparing them to the data from the permanent reference network, to achieve sub-centimetre accuracy.
Now, obviously these networks will have spotted the outage on their own if they're any good, but extra reports amount to saying "Yep, we saw that too"
GPS is also fairly old and run in the aerospace-and-military tradition where every outage requires an announcement made in NOTICES IN ALL CAPS because that's what pilots did in 1950 :)
[1] http://www.bigf.ac.uk/ [2] http://www.epncb.oma.be/ [3] http://www.igs.org/network
The "NOTICE ADVISORY TO GALILEO USERS" (NAGUs) are also all caps (here the announcement of service resumption [1]), like NOTAMs ("Notice to Airmen").
I understand that the Telex network used a 5-bit code with only caps [2], but today? Can't we use Unicode, or even some ASCII variant?
[1] https://www.gsc-europa.eu/notice-advisory-to-galileo-users-n...
[2] https://en.wikipedia.org/wiki/Baudot_code#ITA2
I'm surprised there are quite so many single satellite outages, and no whole-system outages.
What causes satellites to suffer single satellite unplanned outages? Uploading bad software? Bad data? Wrong commands for orbit adjustment?
One would think that after the 20th time these mistakes had been made, automated tests would be in place to prevent them happening again.
Yet it's impressive no whole-network outage has happened. Presumably after uploading data/commands to one satellite, it gets uploaded to the rest. Yet there has never been a time that everything looked okay till after it was deployed worldwide?
The majority of those outages are listed as single-minute, (or as planned downtime).
And there are 31 GPS satellites in orbit when global coverage is possible with only 24.
This, combined with a fully redundant control segment on the ground and a satellite 'autonav' feature that lets them run (with degraded accuracy) for up to 60 days without the control segment provides reasonably good protection against whole-system outages.
There's a bunch of maintenance stuff that happens regularly that's on that list... FCSTDV (stationkeepng burns), FCSTMX (scheduled maintenance, like switching to a different atomic clock or the like), that sort of thing.
There's a lot of recent UNUNOREF on the agi.com link in this thread's grandparent, which is basically "it broke and came back before we could send out a note". If you look closely at that list, though, you'll see that almost all of the recent events are a single satellite -- PRN18. I have no idea what's wrong with it (and AFAIK there's no way for the public to get the details), but it's been going unhealthy for ~2 minutes at a time for months now.
(I'm guessing they keep it live because either don't have another satellite positioned so they can put it into that slot easily, or because they don't consider whatever is wrong with it to be a huge problem.)
The author mentions how they're not going to talk about rumors several times over the course of the article. I'd love to hear what the rumor mill is saying about the possible causes of the outage.
I'm no expert but according to this site, linked in the article, it appears the system has started to come back online and that the issue was limited to the ephemerides: http://www.navsas.eu/node/611
Service was restored yesterday shortly before 9pm UTC: https://www.gsc-europa.eu/notice-advisory-to-galileo-users-n...
It is a massive oversight that the satellites don't mark their own data as bad if not commanded to from earth.
There are lots of reasons ground stations could go offline, and having the satellites broadcast no data is far far better than broadcasting incorrect data.
Anyone in here have a LimeSDR? They look great on paper but I get a sense from what I’ve read that they can be a bit finicky to run.
Also I’m curious about the 1-bit recording. Is that a thing?
1-bit recording is in fact a common thing for very noisy signals. You're actually aggressively over-sampling and using correlations over many samples (in time) to get the signal out from under the noise. I've only glanced over it, but this looks like a fun related article, but driving the opposite way (oversampling to get more effective bits) https://thecavepearlproject.org/2017/02/27/enhancing-arduino...
Thanks! There is a lot on the site, I really liked:
https://thecavepearlproject.org/2015/01/29/a-simple-diy-unde...
Fantastic article! I think i might be able to put this to use with a load cell project to ge a little more precision out if it.
> Also I’m curious about the 1-bit recording. Is that a thing?
Yes. This homemade GPS receiver uses a simple comparator (1 bit) to sample the signal (after amplification to get the noise floor over the decision threshold).
http://www.aholme.co.uk/GPS/Main.htm
> Also I’m curious about the 1-bit recording. Is that a thing?
I'm no expert, but sounds like what you'd do with sigma delta modulation[1]. Basically you use a 1-bit ADC (a simple threshold comparator), but sample at a rate much above the Nyquist rate. The idea is that for a given value of the source signal, the noise inherit in the recorded signal will make some samples register as 0 while others 1.
You then basically average samples to extract the signal you're after.
[1]: https://en.wikipedia.org/wiki/Delta-sigma_modulation#Oversam...
I have had access to a limesdr, bladerf, etc. They are finicky. They're great tools, but it took me a long time to go from toy examples to doing useful things with them.
Any suggestions for where to get started? I've had one sitting for a long while as I had some ideas but I've never done anything
Putting together a gnuradio pipeline to play radio stations or whatever signals you can find is rewarding. Especially when you can get the waterfall spectrogram working
I didn't do anything useful before I had to for work, and it took 10x as long as it should have. I'd suggest just taking some known working examples for fm radio, garage door openers, etc and working through them. It'll be painful, but with enough time and effort it'll happen. And it's sort of like makefile debugging-- the first ten times you have to do it it's excruciating, but after that it turns into just another task you know how to do.
https://greatscottgadgets.com/sdr/
I really second that set of articles. Great introduction.
FWIW there are frontend plugins for LimeSDR that will let it work with SDR# and other standard listening applications. Gnuradio can be extremely frustrating for just basic tinkering.
The software documentation for people new to it is awful. The hardware is probably great, but I've had such a hard time with mine.
It's not newbie friendly at all, and the people in HAM and SDRs don't know how to teach. It's all jargon that they never define or things just like "Oh do XYZ in this software" and that's an entirely non-obvious thing that's entirely undocumented with no tutorials.
A lot of SDR stuff is like you're a person wanting to drive to the store to get some ice cream so you can eat the ice cream. So they give you the blueprints.. to an auto factory. So you can build an auto factory. Which will then build a car. Which you can THEN drive to the store.
Hope there's still ice cream left by the time you get there.
If there's a silver lining, you do learn a lot whether you planned to or not (mostly about how much more other people know than you do).
I first dipped my toes into it with the RTL SDRs back when they were first 'discovered'. I got into listening to local police scanners but got tired of chasing peaks in the spectrum. So I learned a little bit about DSP, wrote a couple of little auto-tuner plugins for one of the more popular SDR applications, built a crude audio pipeline to demodulate the p25, but ultimately had a $1200 PC doing a bad job at being a $200 scanner.
I started to pick it apart more when some genius masochist builds an SDR scanner that does all of the above (including multi-vcos), but then snips out the audio files, tags them with the origin and makes them available for the world to listen via a nice clean web ui. Demoralized and defeated I just moved on to tinker with ADS-B.
Geesh, the nerve of some people. :D
I've got a LimeSDR-mini (which is more economical). If you're only interested in RX, you should definitely consider the cheaper RTL-SDR. I'm just starting to learn about SDR, and am far from sending anything. I wish I had gone with an entry-level device first.
I’ve got at least a dozen RTL’s strewn around the place lol. They are easy to use but once you hit some of their limitations you wind up wanting something more
Nice.
The EU couldn't properly run a lemonade stand.
Before they sunk countless billions into this nonsense the promise was EU's tech independence on the US. Well, it turns out that the worst thing you can depend on in the EU is EU itself.
They designed a new system and made the time fields too short? Again? The ephemeris only has day of the week? No long timestamp? That's embarrassing.
The thing with GNSS is that it is WELL below the noise flow and you need a lot of coding gain to receive it. That on the other hand really reduced the data rate at this you can transmit secondary information such as ephemeris and slowly changing time information. Sending 3 bits for day of week instead of 16 bits or so for a full date makes a real difference for time to the first fix after a cold start.
You clearly haven't read the rest of the article. It's not even especially far down that it's mentioned that the accumulated error for the orbital calculations has resulted in errors for satellite positions into hundreds or thousands of meters after a few days.
They made the time fields short because the information would have no value on timescales larger than that.
The problem is that the time field apparently wraps in a week. Can receivers then tell the data is totally wrong?
Thats what the status bits are for. That they didn't set them to 1 on the full constellation suggests there may have been some trouble they didn't publicize.
The status bit that was set is supposed to mean "working without guarantee" - that is, the satellite may not meet the normal minimum performance level but is still in service. This specific combination of status bits corresponds to a status of "marginal", between full health and actually out of service. In order to actually mark the satellites as fully out of service they'd need to either replace the navigation data with dummy values or upload new navigation data with some additional status bits set.
The whole thing seems a little odd. Even the original 80s GPS satellites could automatically update their ephemeris data with stored predictions for 14 to 60 days after the last contact from the ground segment (with a gradual decrease in the signalled accuracy over time), after which time I believe they would switch to invalid dummy data. The current generation can compute their own ephemeris updates at almost full accuracy for months if the ground segment fails.
I have to wonder how Galileo ended up transmitting such stale data that ground-based recievers ended up mistaking it for next week's data and still marked it as basically valid. That seems like quite an oversight.