Comments inline, old-school (the way it was meant to be) ...
> From: Phil Karn <[email protected]> > Date: Sun, 8 Aug 2021 15:20:40 -0700 > To: "H.Shrikumar KA6Q" <[email protected]>, > Phil Karn via wsjt-devel <[email protected]> > Subject: Re: [wsjt-devel] Anybody working on wsprd these days? > > On 8/8/21 13:20, H.Shrikumar KA6Q wrote: : >> Is it the case that wsprd expects the WSPR pkts to start within a second >> or two of the start of the wav file? Else they dont get picked up? > > I haven't looked at the time synch code, but it looks that way. The WSPR > transmission is 162 symbols at a symbol rate of 12000/8192 Hz, so the > entire transmission is 110.592 seconds long. The input file is 114 seconds Yes, and note, the sync vector is also 162 bits long, and is bit interleaved across the entire packet -- even/odd bits are data or sync. > So if the transmission starts more than 3.408 seconds late, the > tail will be chopped off. > This doesn't mean you'd *necessarily* lose the message. Provided the > time synch search code allowed it to start that late, you could still > decode a truncated message thanks to the interleaving and FEC. But it > would necessarily degrade the SNR performance; it would be as if the > signal faded out entirely during the missing tail. 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. >> Phil's note seems to imply that wsprd uses only 114 seconds of the wav >> file and ignores the rest of the file if it is longer. Is that the case? > > This I'm sure of. From wsprd.c: > nr=fread(buf2,2,npoints,fp); //Read raw data > fclose(fp); Ah, there we are, thanks for the cite into the code. > Right. 3.408 seconds. If I were writing a wspr decoder from scratch I'd > operate in a continuous stream mode that completely ignored timing, > i.e., it would accept a message that started at any time, without need > for an accurate clock. This *would* take (much) more CPU effort, and I > don't know if that would be acceptable without actually trying it. > > My intuition (strongly emphasize "intuition") tells me that many of the > JT modes spend too much channel capacity on synchronization. With > sufficiently strong error detection, and with unlimited CPU for > decoding, you actually don't need synchronization at all. You just try a > decode at every possible frequency and time and see what comes out. > Synchronization just tells you the time & frequency combinations that > are most likely to succeed, so it spends precious channel capacity to > save increasingly cheap CPU cycles at the receiver. 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). 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 did this in the telemetry format I designed for ARISSat-1 (which flew > from the ISS in 2010-2011) and it worked. I had a 128-way convolutional > interleaver, and instead of inserting a synch sequence to indicate the > right interleaver phase I just constructed 128 parallel de-interleavers > and Viterbi decoders and ran all of them in parallel. As soon as an HDLC > frame came out with the right CRC, I stopped the other 127 and kept the > one that worked. What surprised me is that even the 128 > de-interleaver/Viterbi decoders running together took less total CPU > than the PSK demod, because the demod operated at the receiver sample > rate while the de-interleaver/Viterbi decoders operated at the lower > symbol rate. > > I did extend the HDLC CRC from 16 to 32 bits to reduce the chances of a > false decode. And I used a simple noncoherent DBPSK demodulator that > only required the frequency to be approximately correct; it didn't need > to acquire carrier phase. But the JT modes are also designed for fading > channels with relatively short coherence times. 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). 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? >> >> Phil, have you tried playing with the c2 input instead of wav? You could >> feed it I-Q from your SDR signal chain, in that case. Would perform >> better, no? Its mentioned in the man page, but I havent tried it yet. > I've noticed the c2 file stuff, and yes I will probably use it. My SDR > can easily generate an IQ signal 375 Hz wide and centered on the 200 Hz > wide WSPR segment (e.g., 14097.1 kHz, not 14095.6). It looks like a c2 > file is expected to be the full 120 seconds long: 45000 complex 32-bit > floating samples at 375 Hz = 120 sec. 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. >> -- 73 de ka6q Shri > > When I first came to San Diego, I discovered that a local had that call. > I wondered who got it after him, and here you are! > > 73, Phil, KA9Q Heh! Well, I have had this call only a couple of years. As soon as I got my ticket, I went shopping for a call-sign which ends in a consonant, one in particular whose NATO phoetic was a plosive-stop, and, in CW, ended in a dah. Like, you know, FEC-in-the-ear, as it were. 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 _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
