DGPS Logs Aug 5, 2017 UTC 2352 - Aug 6, 2017 UTC 2358 (AFE822x)

[skeezix]

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






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}

[ChrisSmolinski]

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.

[skeezix]

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 E_s has much impact on MW, but perhaps its a different phenomenon with similar results. Or it is E_s.

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.

[ChrisSmolinski]

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. 

[skeezix]

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. 

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.

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.

[ChrisSmolinski]

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 

[skeezix]

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.

[ChrisSmolinski]

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 

[skeezix]

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? 

[ChrisSmolinski]

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.