DGPS Logs Mar 23, 2017 UTC 2359 - Mar 24, 2017 UTC 0059 (AFE822x)

[skeezix]

Got one hour in and looked at the graph...

Youngstown is interesting. The DX is weak to better for station, except for Youngstown. It had a blob of DX earlier on then faded out when the other started coming in. Perhaps Chuck Norris was in Youngstown....






_{AFE822x SDR with 43' Wellbrook ALA100LN loop oriented E-W}

[ChrisSmolinski]

Interesting how the location of DX drifts/moves around. I notice that when I get DX from Europe, as well.  It's like a tracking device for Chuck Norris.

[skeezix]

Yes, definitely. And, this is why I question what I know about propagation.

Was thinking more about it on the drive home, and think there are several things:

- There are modes of propagation that are well known & proven
- There are modes of propagation that we think we know, but not really.
- Then there is that which is yet undiscovered

Analyzing DGPS is showing that there is a bunch of the last one going on. Had some from today (Mar 24)... VA & NY at ~1400 & 1500 UTC, respectively (~1000/1100 EDT & ~0900/~1000 CDT). A time that D+E should've killed propagation from VA & NY to MN, yet, it was open for a short time. Why? Those are 1671 km & 1170 km.

While I love the long distance nighttime DX, I find the daytime DX more interesting.

[ChrisSmolinski]

Agreed, there is still quite a bit to learn about propagation. One reason DGPS band can be interesting because it sits at the intersection of the traditional definitions of the LF/Longwave (30-300 kHz) and MF/Medium Wave (300-3000 kHz) bands. We like these neat and tidy band allocations and descriptions of propagation, but there certainly seems to be a lot more going on.

A lot of the "rules" of propagation don't always seem to apply. A high K index is supposed to be bad. But sometimes on those nights, I get quite a bit of interesting DX. I recall years ago some MW DXers refer to these high K index nights as "stirring the gumbo", providing a different mix of stations, vs what you normally hear.

The daytime DX is fascinating, when a station will appear for a short time, then vanish. I wonder if we will continue to see this during the middle of summer.

The DGPS band is narrow, only 40 kHz wide and low in frequency. I wonder if some sort of SDR could be built that just targets this band. A 1 MHz sample rate A/D would be more than adequate, and a band pass filter would allow just the DGPS band to be fed to the A/D. Then decimate to produce say a 50 kHz sample rate, which covers the entire band. Feed that to a Raspberry Pi or similar, and do real time decoding, sending just the decodes via ethernet (or even WiFi?) to another computer where they can be stored and analyzed. Or stored on the RPi flash drive and then periodically downloaded. You could have a dedicated DGPS monitoring station running 24/7. 

[skeezix]

The definitions of the bands are some arbitrary thing that we made up. Nothing magical happens between 299.5 kHz and 300.5 kHz. But, there is certainly differences in propagation we see on the MW band between stations on 540 kHz and stations at the high end.

And yeah, those "rules" ... they need to be investigated & revised. They're a good starting point and for the most part explain things, but they do not explain everything.

I really, really like your idea of a RPi doing live decoding with a specialized DGPS SDR. Think we could convince Alex to design & build something for us?

Wouldn't want the RPi doing too much and certainly not long term storage

One program that does the decoding, which sends its data to another program on the RPi that listens to that then writes to a temp log on the flash disk and listens on the network for systems that want its data. One remote system could be defined as a primary, so it could get a backlog of data when its not connected. Other systems would simply get the data when they're connected and if they're not connected, then nothing is saved. That distribution program on the RPi, could also have a version that could be on another system on a fast connection, so a VPS somewhere could have a single connection to the RPi for its data, then the rest of the world would connect to that and it would relay instead of adding pressure to the RPi.

Yeah, I think there's something here alright.

[ChrisSmolinski]

It's been a while since I have done FGPAs, but I think a modest (by today's standards) FPGA could do quite a bit of the work for us. Not sure how many bits we really need on the A/D. I always think more is better but noise levels on the DGPS band are fairly high. At these low sample rates the A/D should be fairly cheap.  To avoid building hardware, I would love to find an existing board that has an A/D and FGPA that we can just interface to the RPi.

[skeezix]

I don't know anything about programming those things, but from what I've seen for FPGAs in other application, it may work.

Would it also be useful to put the decoder in an FPGA, or, combine the SDR & decoder in an FPGA? I have no idea (obviously).

[ChrisSmolinski]

Sure, the more that can be put into the FPGA, the less the RPi has to do. I suppose it would be possible to put *everything* in the FPGA, with the final output being the decodes. Then you can throw away the RPi 

I am not sure how large of an FPGA you would need, however, and what that would cost. OTOH if the RPi can do most everything inside code, that makes this a cheap (from hardware POV) project. I doubt that is possible, however. I guess the first step would be to transfer the DGPS demod code over to a RPi and see how it runs, reading from an I/Q file on disk. That would be a reasonable benchmark.

[skeezix]

I agree with that. Let's see what a RPi can do with the recording.

Time to order a RPi. Think I'll do that this weekend.

[jFarley]

There is some interesting info here:

http://www.infotechcomms.net/Understanding_LF_and_HF_propagation.pdf