This activity is pretty much continuous during Western Hemisphere daylight hours, up from 14233 kHz, going as high as maybe 14233.35 at times. They continue to transmit the callsigns in the waterfall. Despite a continuous voice chatter (some kind of orderwire, plus a guy talking about his '53 De Soto) no signals have been anywhere near strong enough here for a decode.
UPDATE 1930 UTC: Currently the USB voice orderwire is on 14320.0, but the correct tuning for the digital signal is 14233.24 +/- around 200 Hz. Mention was made (following the '53 De Soto discussion) of another program called EasyPAL. This apparently implements another widely used mode called HamDRM (Presumably Digital Radio Mondiale). Unfortunately, it crashes and burns if you are using hyperthreading on dual-core Wintel machines with XP Service Pack 2. You have to turn this off in the BIOS, and I didn't feel like doing that, since I use the feature a lot with other processor-eating apps to still have a usable computer for things like radio, while they're thinking away.
UPDATE 2036 UTC: Still nothing even close to decodeable signal levels. Apparently the mode needs a good steady S8 or 9 for perfect reception, and not too much lower for any decode at all. Unless someone local transmits, that is not going to happen on 20 meters at this time of day at this point in the cycle. This explains why I seem to be the last hard core radio hacker ever to hear of digital SSTV. Like so much of HF amateur radio, it is just not that rewarding without the use of large rotary antennas on tall towers, of a sort that will get you sued in most decent US neighborhoods.
This is in contrast to analog SSTV, which will decode even when below the noise, though you don't get much. At least you know your software is trying.
So it goes in the exciting world of digital radio. I knew there was something to be said for R-390s and straight CW.
UPDATE 2205 UTC: Downloaded a new DRM DLL for DIGTRX. For some inexplicable reason, the entire folder is set read-only, perhaps because the program is running. Resetting it only causes it to be set back. An effective work-around was to rename the old DLL while out of DRM mode, then copy in the new one. Now DRM mode of DIGTRX does not crash with hyperthreading enabled. (Of course I could always have tried exiting the program...)
DRM has the advantage that you can indeed watch your software try to achieve a decode, complete with a nice phase constellation to show how things are going. At least the listener knows something's happening.
Still no decodes, however. Dial reading when on-channel in this mode is 14232.95.
