On 8/8/21 6:41 PM, H.Shrikumar KA6Q wrote: > Comments inline, old-school (the way it was meant to be) ... Right!!
> Indeed. But loosing SNR in the decoder denies the Gods of Propagation > their due offerings, ... so lets count that out. And then there is the sync > vector itself, of which you have to be tolerant of only getting a portion. There should be no need to receive the entire sync vector when the SNR is high. The correlator at the receiver that looks for it will still give a peak when it finds part of it, only the peak will be lower. So again, chopping off the tail of the message degrades the SNR, but doesn't make it impossible to receive. > > Yea, its worth the thought. In fact, I just recently started on an effort to > do something like that, to dig out more signals that are otherwise perfectly > WSPR compliant but slipped in time. It has a particular application with > regard to my project -- which builds upon coherent correlating across > multiple geographically WSPR receivers (shunting to a different thread, > if there is interest). I suspect this would require a major restructuring of WSJT-X since it seems to assume near-correct timing on everything. Correct me if I'm wrong (I haven't been through much of the code base) but the decoders seem to operate in a "batch mode". Each is passed a fixed-size file containing one time slot of the format that assumes near-correct timing from all the signals within it. True? Arbitrary timing would require a major restructuring. You could either keep the existing decoders and feed them fixed-sized files that are staggered and overlapped in time (e.g., launching a copy of wsprd every 6 sec). Or you could rewrite all the demodulators to operate in a continuous stream mode, which would be an even bigger job. I go back and forth on the utility of this. GPS is now so cheap and easy that timing doesn't seem like much of a requirement. You can get it even in the most remote places on the globe (that's what the "G" means). In practice, the main obstacle to getting GPS seems to be when you're inside a building where you can't put up an outdoor GPS antenna, and in most of those situations you have Internet access to NTP. OTOH, we're hams; do we want our stuff to rely on the Internet? > > But more generally, I hope such a set of "timeless" decodes might be a > potentially useful contribution to the community, because we may be able to > dig out some stats on how many WSPR transmitters are way off time sync. I > am sure there must be such beacons, and we just dont know. > > Hence my recent interest in the wsjt code base, and why my interest was > piqued when I saw your note on wsprd. I could find out with my current setup. I can easily implement the overlap approach I mentioned earlier using an unmodified wsprd. It'll cost more CPU, but who cares? > > Yes I have seen reported that HF QSB can introduce 2 or 3Hz or so phase > modulation at the 20m band (IIRC the QST paper on Coherent CW had some > anecodotes on a JA to W6 path in this regard). Which will impair WSPR since the symbol rate is only ~1.46 Hz. The Doppler can spread the symbol energy out of a demodulator FFT bin. > > So the numbers will have to be worked out I guess. If the prefix of the > sync vector that serves the same purpose as your ARISSat-1 frame-sync/CRC > needs to be increased to a point where it is what the whole 162 bit sync > vector in WSPR is now, then it may be a wash? The only "frame sync" in my ARISSat-1 format was the 8-bit HDLC flag between the frames. This was still necessary because the HDLC frames vary in size. (One of the reasons I chose HDLC was because the rest of the team couldn't decide on a single fixed telemetry frame size.) The HDLC flag was scrambled and convolutionally encoded along with the body of each frame and the CRC. This produced a featureless bit stream that was then convolutionally interleaved 128 ways and then fed to the DBPSK modulator. The CRC is for error detection, which is still essential here. Otherwise there's no way, even with infinite CPU, to determine when I had the correct interleaver sync. That's why I said that *provided you have sufficiently strong error detection*, you can just try to decode every possible combination of time and frequency and see what comes out. From experience with AX.25 I knew that the 16-bit CRC in HDLC was weak enough to let through lots of short garbage frames on noise, that's why I lengthened it to 32 bits. WSPR uses a r=1/2 k=32 convolutional code. At the end of each message it flushes the convolutional encoder with 31 0-bits to return it to all-0s (same as the starting state). These "tail bits" provide the error *detection* you need here, because it is very unlikely for my Fano decoder to make it all the way through the tail with corrupt data unless you set the decoding time limit *very* high. While it's not a CRC, the tail serves a very similar function. When you set a decoding limit, you are making a trade off between error *correction* and error *detection*. Too small a limit, and you erase (throw away) frames that might have decoded correctly. Too high a limit and you risk decoding a frame incorrectly (getting garbage marked as correct). EVERY coding scheme has this trade off, whether or not you actually tweak the knob. Even a CRC can be used for error *correction* at the expense of decreased error *detection* So once you have sufficiently strong error detection, any additional synchronization in the signal is just a hint to the proper time and frequency combination, to help the receiver save CPU time. My initial look at wsprd says that's exactly what they do - look for correlation peaks on the sync vector, sort the list list in decreasing amplitude, then walk down the list attempting decodes starting with the most likely ones. > > Yes c2 file support included in wsprd was thoughtful.. .wav might be more > common for typical testing, but when it is feasible, c2 would be better > by a 3dB step for any build-upon-it experiementation .. so its nice to > see it included there. Why should there be a 3dB difference? It saves some CPU time in wsprd, but I don't see why it should have any effect on decoding performance. > > KA6Q leapt out in the available list because, to me, it was 2/3rds of KA9Q .. > a call-sign I have been following for years in various bits of radio and > network data stuff I have been doing, or interested in. (for eg, my iPic > "256-byte web-server" was front-ended by a ka9q router). > > I saw it, jumped and grabbed. So yea, sincerely, there's a connection :-) > > -- 73 de ka6q Shri Thanks. :-) 73, Phil KA_9_Q
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
