Transmitting into a dummy load .. for a year .. on purpose. Podcast Por  arte de portada

Transmitting into a dummy load .. for a year .. on purpose.

Transmitting into a dummy load .. for a year .. on purpose.

Escúchala gratis

Ver detalles del espectáculo
Foundations of Amateur Radio Just under a year ago I started an experiment. I set-up a beacon for WSPR, or Weak Signal Propagation Reporter, transmitting at 200 mW into a dummy load using eight bands between 80m and 10m. I also set-up an RTL-SDR dongle, connected to an external 20m HF antenna and made it monitor 18 amateur bands between 630m and 23cm. I left this running 24/7 for most of the year, though there were times when I detached the antenna due to local thunderstorms and there was a seven week period where there were no reports. It's highly likely that I forgot to reconnect the antenna, but I don't recall. For this analysis I used the online WSPRnet.org database where I uploaded my spots as they were decoded. I noticed that there are reports that I have locally that are not in the database, though I'm not sure why. They're incomplete and not in the same format and merging these is non-trivial for reasons I'll discuss. Lesson learnt, the "rtlsdr-wsprd" tool needs to be patched to output the data in the same format as is available from the online database and I need to actively log locally. The results are puzzling, at least to me right now. Let's start with the low hanging fruit. There are no reports of my WSPR beacon being received by anyone other than me. That doesn't guarantee that nobody heard me, just that nobody reported that they did. In the database there's just over six thousand reports of my station receiving a WSPR transmission from my beacon during the past year. The reports cover all bands, though not equally. The 80m band represents 6 percent of reports, where 40m accounts for 20 percent. The reported SNR, or Signal To Noise ratio, varies significantly across the data. For example, the 12m band shows a range of 42 dB. Digging into this does not reveal any patterns related to date, time of day, season, other band reports or any other metric I was able to imagine. In my exploration, missing records and time-zone differences aside, I discovered that the local data does not appear to match the database. For example I have records where the software decoded my beacon ten times in the same time-slot, but none of them exist in the database. For others, there's only one matching record, which leads me to believe that the WSPRnet.org database only accepts the first report for any given combination of timestamp, transmitter and receiver, but I have yet to confirm that. So, let's talk about getting more than one result for a specific time-slot. As you might know, a WSPR signal is transmitted every 120 seconds, starting at the even minute. Each transmission lasts 110.6 seconds. The decoder will make several attempts to decode multiple, potentially overlapping signals. It is my understanding that the way this happens is by essentially removing a known decoded signal and then attempting to decode what's left, repeating until either there's no more signals to decode, or time runs out, since there's probably only really 9.4 seconds in which to do this. Potentially this means that a faster computer will decode more signals, but I've not actually tested that, but it's probably something worth pursuing. Back to our decodes. If the first decode is removed from the received data and the next decode gives you similar information, same callsign and maidenhead locator, with SNR and frequency differences, then you might imagine that there's so much of it there that the only way that might happen is because the receiver is overloaded. I'm still looking into this, because if that's the case, then we'd need to determine if the receiver was always overloaded, or only sometimes. It's curious, since there's over a thousand other signals being received from other stations, several over 18,000 km away, so it's not like the receiver is completely swamped. Another hypothesis is that the decode is coming from a different band, like a harmonic. This is potentially caused because from a band and timing perspective, the receiver isn't linked to the transmitter in any way. The transmitter hammers away 24/7 one band after the next, switching every two minutes, the receiver listens for half an hour on a band, then randomly picks the next, until it runs out of bands and starts again. The receiver is listening on more than twice as many bands as the transmitter operates on, but that doesn't mean that it cannot hear the transmitter on a harmonic of one of the bands. Again, I don't know if this is the case, or if something else is happening. One thing I'd expect, is to see reports on other harmonics outside the bands that the transmitter is using, but I'm not seeing that. Perhaps the overload is limited to just the band we're actively monitoring and the other signals are coming in regardless of the overload. I'm still trying to determine if that's the case. As I said, merging the data from the two sources is non-trivial, time-zones and formatting are not the same and I'm not in the mood for manually ...
Todavía no hay opiniones