HFU HF Underground
Loggings => DGPS => Topic started by: skeezix on November 27, 2016, 2045 UTC
-
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¤tOutages
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
(http://i.imgur.com/zgb6E4l.png)
Perseus SDR with Wellbrook ALA1530S+ loop antenna oriented N-S
-
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.
-
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.
-
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?
-
If changing the max zCount fixed it, then it sounds like the file's timestamp (the starting time) is wrong.
-
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.
-
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.