DGPS Logs Nov 27, 2016 UTC 0145 - Nov 27, 2016 UTC 1508

[skeezix]

All of these appear to be valid.

Nothing interesting in the stations, but what on earth happened between ~1100 and ~1220Z? There are some decodes, so I know it had some data. I'm running it again with all of the files and see what happens. When looking at the recordings in the Perseus s/w, can def see QRM, but it existed long before 1100Z and went until around 1420Z, otherwise, all of the stations are there happily transmitting with 317 being very strong and shouldn't have been interrupted like that.

Initially thinking this may have been widespread status, did find the USCG's DGPS status page. Looks like a few will be going offline briefly in the next few weeks:
http://www.navcen.uscg.gov/?pageName=dgpsSiteInfo&currentOutages


Here's the data from from the first run (when the second run is done, if it looks better, this data & the graph will be replaced)
Count    ID   ref1 ref2 kHz   Baud City                           Country              Lat      Lon      km     Deg
4        927  316  317  309.0 200  Lauzon, QC                     Canada               46.821   -71.165  1,729  75  
10       839  118  119  322.0 100  Youngstown, NY                 United States        43.239   -78.972  1,170  95  
10       888  276  277  302.0 100  Whidbey Island, WA             United States        48.322   -122.706 2,249  290
16       847  058  059  301.0 200  Annapolis, MD                  United States        39.018   -76.61   1,538  110
72       909  300  301  309.0 200  Alert Bay, BC                  Canada               50.589   -126.93  2,554  296
164      881  262  263  302.0 100  Point Loma, CA                 United States        32.677   -117.25  2,462  244
682      886  272  273  287.0 100  Fort Stevens, OR               United States        46.208   -123.96  2,363  284
1034     972  901  902  302.0 200  Miraflores                     Panama               8.993    -79.585  4,220  157
1065     816  032  033  304.0 100  Aransas Pass, TX               United States        27.842   -97.065  1,936  191
1082     870  170  171  309.0 200  Reedy Point, DE                United States        39.569   -75.572  1,585  106
1542     804  008  009  286.0 200  Sandy Hook, NJ                 United States        40.475   -74.02   1,659  101
2050     772  198  199  306.0 200  Acushnet, MA                   United States        41.749   -70.889  1,852  93  
2073     836  112  113  292.0 200  Cheboygan, MI                  United States        45.656   -84.475  704    81  
2623     809  018  019  289.0 100  Cape Canaveral, FL             United States        28.467   -80.554  2,162  144
3579     844  094  095  324.0 200  Hudson Falls, NY               United States        43.272   -73.542  1,595  90  
3804     871  172  173  300.0 100  Appleton, WA                   United States        45.792   -121.332 2,168  282
12729    806  012  013  289.0 100  Driver, VA                     United States        36.963   -76.562  1,670  116
14223    808  016  017  314.0 200  Card Sound, FL                 United States        25.442   -80.452  2,468  147
14335    778  192  193  292.0 100  Kensington, SC                 United States        33.491   -79.349  1,759  132
17911    771  196  197  294.0 100  New Bern, NC                   United States        35.181   -77.059  1,765  123
23753    828  246  247  301.0 100  Angleton, TX                   United States        29.301   -95.484  1,756  187
23871    831  102  103  298.0 100  Upper Keweenaw, MI             United States        47.233   -88.628  446    55  
25796    830  100  101  296.0 100  Wisconsin, Point WI            United States        46.708   -92.025  219    30  
27541    838  116  117  319.0 200  Detroit, MI                    United States        42.306   -83.103  883    106
27774    865  160  161  320.0 200  Millers Ferry, AL              United States        32.095   -87.397  1,528  158
33683    827  244  245  312.0 200  Tampa, FL                      United States        27.85    -82.543  2,138  149
35022    814  028  029  293.0 200  English Turn, LA               United States        29.886   -89.947  1,709  169
44288    792  136  137  297.0 200  Bobo, MS                       United States        34.125   -90.696  1,233  168
44419    777  218  219  304.0 200  Mequon, WI                     United States        43.202   -88.066  474    113
45475    866  162  163  299.0 200  Sallisaw, OK                   United States        35.369   -94.817  1,078  187
48480    862  154  155  322.0 200  St Louis, MO                   United States        38.619   -89.764  773    156
50232    863  156  157  311.0 200  Rock Island IL                 United States        42.02    -90.231  421    141
51338    864  158  159  317.0 200  St Paul [Alma], MN             United States        44.306   -91.906  144    122







_{Perseus SDR with Wellbrook ALA1530S+ loop antenna oriented N-S}

[ChrisSmolinski]

I ran a test last night, using the netSDR instead of the AFE822, and ran it in 24 bit mode. The results were unimpressive, but the K index was high, so who knows what was going on. 

skeezix: Does your missing data correspond to an I/Q recording file? Perhaps the file was bad, or maybe it had a bad timestamp? You could check the latter by re-running just that file, and set the max zCount error to a large number like 99999 so the check is not performed. If the stations appear as normal, then that was the problem.

[skeezix]

The missing decodes are from a couple of files, starting part way into one of them. A little suspicious of the decodes once it started up again-  would expect more from Kensington & New Bern. Could be more problems with decoding that didn't fully recover, or the stations just happened to fade out. Can't wait until the AFE822 arrives, then can have two of these things going on separate antennas.

I looked at the files and there was nothing of interest at the time of good decode to when it stopped (at least visually or audibly).

Once this batch of 11 are done, I'll review the results. If there is missing data, I'll isolate and process to only the ones that show problems.


A "good" thing with all of the QRM here (currently have two strong & disctinct sources, one that's NW-SE from me and another that is NE-SW  ), is that this is an opportunity to see how resilient the DGPS signals are to QRM.

[skeezix]

Ran it again with Max zCount still set to 6 and it behaved the same. Set it to 999999 and now its decoding. Did get it to decode around 20, but seemed as not as many as when at 99999, but more than 6.

The time on the PC should've been accurate as there is a time sync program on there (from Meinberg, not using the stupid & useless m$ joke of a time sync thing).

Is there something I can check in the I/Q file to see what's its problem is?

[ChrisSmolinski]

If changing the max zCount fixed it, then it sounds like the file's timestamp (the starting time) is wrong.

[skeezix]

That would be odd, as the first 3 or so minutes decode fine. I started the recording hours earlier, and Perseus makes 80 min (~3.5 GB) files, and this is file #8 with no intervention.

What is the format for the Perseus files? I might take a peek inside and see what its up to.

Unless... at that time, my system found a new NTP peer and it was off, which would've been weird.

[ChrisSmolinski]

That would be odd, as the first 3 or so minutes decode fine. I started the recording hours earlier, and Perseus makes 80 min (~3.5 GB) files, and this is file #8 with no intervention.

That's interesting. I can see two possibilities:
1. ADGPS keeps track of the "current" time in the file based on the starting timestamp, and how many samples it has processed.  if there was a glitch, and several seconds of missing data (or I guess extra data could also do it), that would throw the current time into the file off, causing the zCount check to fail.

2. Sample rates are always wrong. They're usually off by a fractional percentage, but over a very long recording, it would be enough to throw things off by a few seconds by the end of the file. ADGPS compensates for this by using the zCount information from good decodes, to compensate for this drift. If you somehow got a bunch of decodes that otherwise passed the various checks, but had bad zCount information, it could throw things out of whack. I think I have seen this happen once before. When the next file is processed, ADGPS uses the timestamp at the start of the file to reset the current time, and decodes would begin normally again.