HFU HF Underground
Loggings => DGPS => Topic started by: skeezix on August 07, 2017, 0016 UTC
-
Sandspit
Sunday, August 6, 2017 10:00:36
Sunday, August 6, 2017 10:00:59
Count ID ref1 ref2 kHz Baud City Country Lat Lon km Deg
1 001 962 001 324.0 200 Gizan Saudi Arabia 16.883 42.533 11,823 44
2 906 306 307 300.0 200 Sandspit, BC Canada 53.242 -131.814 2,898 302
38 942 340 341 288.0 200 Cape Ray, NL Canada 47.636 -59.241 2,621 71
6 885 270 271 292.0 100 Cape Mendocino, CA United States 40.447 -124.405 2,563 270
240 909 300 301 309.0 200 Alert Bay, BC Canada 50.589 -126.93 2,554 296
1 808 016 017 314.0 200 Card Sound, FL United States 25.442 -80.452 2,468 147
1 881 262 263 302.0 100 Point Loma, CA United States 32.677 -117.25 2,462 244
223 908 302 303 315.0 200 Tofino [Amphitrite Point], BC Canada 48.931 -125.545 2,456 292
2319 764 210 211 314.0 200 Lincoln, CA United States 38.855 -121.361 2,395 263
1832 886 272 273 287.0 100 Fort Stevens, OR United States 46.208 -123.96 2,363 284
3651 907 304 305 320.0 200 Richmond, BC Canada 49.114 -123.183 2,283 292
1 935 334 335 312.0 200 Western Head, NS Canada 43.993 -64.67 2,273 83
54 888 276 277 302.0 100 Whidbey Island, WA United States 48.322 -122.706 2,249 290
36 887 274 275 323.0 200 Robinson Point, WA United States 47.392 -122.38 2,230 287
1624 871 172 173 300.0 100 Appleton, WA United States 45.792 -121.332 2,168 282
19 809 018 019 289.0 100 Cape Canaveral, FL United States 28.467 -80.554 2,162 144
1 939 326 327 295.0 200 Partridge Island, NB Canada 45.239 -66.056 2,138 80
1152 827 244 245 312.0 200 Tampa, FL United States 27.85 -82.543 2,138 149
2201 799 044 045 290.0 200 Penobscot, ME United States 44.453 -68.776 1,942 83
4711 772 198 199 306.0 200 Acushnet, MA United States 41.749 -70.889 1,852 93
8166 771 196 197 294.0 100 New Bern, NC United States 35.181 -77.059 1,765 123
207 778 192 193 292.0 100 Kensington, SC United States 33.491 -79.349 1,759 132
232 828 246 247 301.0 100 Angleton, TX United States 29.301 -95.484 1,756 187
3736 803 006 007 293.0 100 Moriches, NY United States 40.794 -72.756 1,743 98
3831 927 316 317 309.0 200 Lauzon, QC Canada 46.821 -71.165 1,729 75
12 814 028 029 293.0 200 English Turn, LA United States 29.886 -89.947 1,709 169
7639 806 012 013 289.0 100 Driver, VA United States 36.963 -76.562 1,670 116
1998 804 008 009 286.0 200 Sandy Hook, NJ United States 40.475 -74.02 1,659 101
19637 844 094 095 324.0 200 Hudson Falls, NY United States 43.272 -73.542 1,595 90
176 929 312 313 296.0 200 St Jean Richelieu, QC Canada 45.324 -73.317 1,574 82
9087 847 058 059 301.0 200 Annapolis, MD United States 39.018 -76.61 1,538 110
624 919 308 309 306.0 200 Cardinal, ON Canada 44.783 -75.417 1,417 85
14867 792 136 137 297.0 200 Bobo, MS United States 34.125 -90.696 1,233 168
14078 839 118 119 322.0 100 Youngstown, NY United States 43.239 -78.972 1,170 95
1965 918 310 311 286.0 200 Wiarton, ON Canada 44.75 -81.117 971 87
19756 838 116 117 319.0 200 Detroit, MI United States 42.306 -83.103 883 106
15471 836 112 113 292.0 200 Cheboygan, MI United States 45.656 -84.475 704 81
92493 777 218 219 304.0 200 Mequon, WI United States 43.202 -88.066 474 113
44129 831 102 103 298.0 100 Upper Keweenaw, MI United States 47.233 -88.628 446 55
49256 830 100 101 296.0 100 Wisconsin, Point WI United States 46.708 -92.025 219 30
(http://i.imgur.com/NitGZcr.png)
CURRENT DGPS ADVISORIES FOR 06 Aug 2017
Site Name Site Id BNM # OUTAGE MESSAGE
SCHEDULED / UNSCHEDULED OUTAGES
Tampa (Macdill) 827 0276-17
BROADCAST SITE STATUS IS UNCONFIRMED DUE TO NETWORK OUTAGE AS OF 07/25/2017 13:53 Z UNTIL FURTHER NOTICE.
GENERAL INFORMATION
Reedy Point 870 0204-17
DGPS BROADCAST SITE WILL PERMANENTLY CEASE BROADCASTING CORRECTIONS ON 31 JULY 2017 AT 1400Z
CANADIAN DGPS OUTAGES
CURRENT CANADIAN DGPS ADVISORIES FOR 06 Aug 2017
Site Name Site Id BNM # OUTAGE MESSAGE
SCHEDULED / UNSCHEDULED OUTAGES
Western Head N011-17
BROADCAST SITE IS OFF AIR AS OF 07/25/2017 15:00 Z UNTIL FURTHER NOTICE.
AFE822x v2.0 SDR with 43' Wellbrook ALA100LN loop oriented E-W
-
Sandspit is always a tough catch here. It did not appear last night. It did appear 1-2 Aug, which was that spectacular DGPS night we had a few days ago. Even then, just 2 decodes. That was the night I got Alert Bay, BC and Biorka, AK. Which brings up another possible way to decide whether decodes are real or not. Look for associated stations. If I get a bunch of stations (or higher decode rates) from BC/Alaska/West Coast then I can assign a higher probability to them being real. Likewise, if I get a bunch of Euros, or say I get solid decodes from Azores and Madeira, and there's a few European stations with just 2 or 3 decodes each, it seems more likely they are legit. I've not been seeing any European stations in the decodes lately (which is how I expect it to be). But if a bunch of them appear on one night, then perhaps they are legit. Closely spaced logs (on a time basis) are also signs they could be real.
Likewise if they are at a similar time to other stations from that same area. But not necessarily at exactly the same time. I'm not exactly sure how to describe this, but it seems like there is a blob on the map that moves around. The blob is of unknown size. When the blob is over a station, you get decodes from it. Think of it as one end of the propagation pipe that connects to your QTH. Some of this can be roughly estimated, not only can't I get the west coast stations until the path is dark, but it also has to have been dark for a sufficient amount of time. Maybe that is so the D layer has time to completely dissipate. In the summer, you rarely have that much time before it gets light again here, so the west coast stations are much tougher than in winter. For me anyway, propagation to the west coast is best just before local sunrise. I don't think this is any sort of a greyline effect, since the west coast stations are not on the greyline. Rather I think it is because that is when the path has been darkest for the longest time period. Likewise European stations usually come in best just before their local sunrise.
I do keep the minimum number of counts set to 2, which keeps out the riffraff. Turning it on to 1, for last night's decodes I get one for Sandspit at Monday, August 7, 2017 08:53:32. Which is plausible. But I also get China, Russia, Germany, Finland, Azores, etc. at completely impossible times. If you can't produce at least 2 logs, your station is unimportant, and I do not see your decodes.
It's unfortunate that there is a lot of human/manual interpretation of the decodes required to decide what is and is not likely to be legit. It would be nice to further automate it, but I am not sure how. In the end it sometimes boils down to a judgement call.
If jFarley is reading this, I am curious what his observations from NDB DXing are. Or any other longwave DXers of course.
-
I agree with you.
I leave the 1 decode stations in to see what else turns up, esp on the 0.5 kHz channels. I still don't call that valid, but it is interesting at times.
That blob you speak of sounds just like sporadic-E that we see on 6m and other bands. I'm unsure if Es has much impact on MW, but perhaps its a different phenomenon with similar results. Or it is Es.
Is there a way you could dump out the full messages from the one/two decode stations? You've said before getting the message back to the main prog would be hard, but could the thread dump the message in its own file? Sure, might have a dozen files running around, but this would be only for analyzing the decodes to get to the bottom of this.
Not sure the internals for ADGPS, so this may not be feasible. Or, it won't know if its a 1 decode station until the end, but perhaps if the station ID is > 5000km away (or a hard-coded set of candidates), then dump the message & the previous.
More than these fake decodes, I'd really like to know the reasons of variations in decoding when running ADGPS on the same recording files multiple times. Perhaps some instability in the decoding process that is shown here also manifests itself in the single fake decodes?
I don't know.
-
Is there a way you could dump out the full messages from the one/two decode stations? You've said before getting the message back to the main prog would be hard, but could the thread dump the message in its own file? Sure, might have a dozen files running around, but this would be only for analyzing the decodes to get to the bottom of this.
Not sure the internals for ADGPS, so this may not be feasible. Or, it won't know if its a 1 decode station until the end, but perhaps if the station ID is > 5000km away (or a hard-coded set of candidates), then dump the message & the previous.
There's no (easy) way to store entire messages until the end of the decoding session. It might be possible to dump all the decodes as they happen. Would you just want the raw 60 bits? I could write out a 64 bit word for each decode. Trying to think of something that is relatively easy and likely to work in a multithreaded environment, since there is one decoding thread running for each channel/baud combo. They could all get spit to one file. Hmm. But I guess you want a timestamp also. So maybe you get 96 bits. Could I do this just for the Mac? It's much easier for me to modify the shared library for the Mac vs Windows. Meaning it is much more likely to actually happen. ;D
-
There's no (easy) way to store entire messages until the end of the decoding session. It might be possible to dump all the decodes as they happen. Would you just want the raw 60 bits? I could write out a 64 bit word for each decode. Trying to think of something that is relatively easy and likely to work in a multithreaded environment, since there is one decoding thread running for each channel/baud combo. They could all get spit to one file. Hmm. But I guess you want a timestamp also. So maybe you get 96 bits. Could I do this just for the Mac? It's much easier for me to modify the shared library for the Mac vs Windows. Meaning it is much more likely to actually happen. ;D
Just Mac is perfect, then I have lots of tools to work with. With Windows, I'd just copy it to Mac/FreeBSD/Linux anyway to work on. This saves a step. :D
This is for debugging specific things and I won't be processing 24h of recordings, just select things in the night to see what pops up.
Would want time and full message with headers.
Actually, would like the headers as well. 30-bit word 1 header + 30-bit word 2 header + all of the message words.
How big are the messages? Do they cap at 60-bit (two 30-bit words)? From RTCM-SC104, it seems like they could go larger.
How about this format (this might be insane):
<32-bit timestamp (epoch secs)> <32-bit header 1> <32-bit header 2> <32-bit message word 1> <32-bit message word 2> ... <32-bit message word n> F0F0F0F0F0F0
Since they're 30-bit words from the transmission, pad 00 at the front.
F0F0F0F0F0F0 (or something we're not likely to find as a message or time) as a marker to end of message. This would provide an easy method to determine message boundaries and to delineate them in case the header is corrupt. Could probably work without that, looking for the next timestamp, but looking for a static value is trivial.
-
Actually, would like the headers as well. 30-bit word 1 header + 30-bit word 2 header + all of the message words.
I don't decode the other message words, just the first two. So that's all there is :)
-
I don't decode the other message words, just the first two. So that's all there is :)
Ohhhhhh... ok.
Then amend my previous thought to 32-bit words of: timestamp, header 1, and header 2. Forget that word about F0F0F0F0F0, since three 32-bit words fits the bill exactly.
-
I guess you might want the frequency and baud rate also? Although those could be determined from the station info it might be nice to have. Plus then I can write four 32 bit words. Which somehow seems better than three ;D
-
Frequency only if you determine what it is. Simply looking it up, then no.
And I believe you spawn different baud rates, which obviously know what they're doing, then that would be useful too.
I think that's it? ;D
-
Frequency (and baud rate) would be from the decoder thread itself, so yes, what was actually used. Which should always match what it should be for that station, since it is checked before the decode is passed through. I guess you could use it as a test to make sure something didn't sneak past the check.