After talking to knowledgeable people on the digital SSTV group, I have decided that the "virus" detected by Norton is a legitimate file distributed with the program.
The confusion seems to be stemming from Norton's detection of a file called loop.zip, which contains a Windows library file called loop.dll. Loop.dll has been around for a few years, and it contains routines that are sometimes used with SDRs. However, another file named loop.exe is associated with several known Trojans.
This leaves only the odd question of why loop.zip would be recreated whenever EasyPal ran. After I completely uninstalled EasyPal, this behavior stopped, so there's no evidence that the system is doing it.
I have not tested the latest version of EasyPal, which is only a few weeks old, to see whether it, too stops this behavior. However, I now once again consider it excellent software.
Apologies to the programmers of EasyPal, who have really done a nice job bringing hams a more reliable way to use a complex mode.
Other discussions have centered on the widely known fact that there are probably better anti-virus packages on the market than Norton. While my version is better than the previous two or so, it's still pretty bloated and prone to causing issues such as this one with EasyPal.
Sorry about that.
Showing posts with label sstv. Show all posts
Showing posts with label sstv. Show all posts
Wednesday, March 17, 2010
Monday, March 15, 2010
Possible Issue With EasyPal
Some people might have noticed that the glowing review of the EasyPal software has been deleted from this blog. This is because of various strange virus detection issues that many users, myself included, have gotten since the start of 2010 while using this program.
A rather spirited discussion of this subject is on QRZ. There's another on the DigiSSTV Yahoo! group.
The areas of agreement are as follows:
1. EasyPal detects as clear of malware on all checkers when its files are scanned on first installation.
2. At some point after the first picture is viewed, various different virus checkers start to show various different Trojan loaders in EasyPal's directories. MalwareBytes seems to do this the most often. (There is no agreement on whether or not these are false positives.)
3. After this detection, EasyPal still shows as clear. The alleged virus is in a more recently created file that was not distributed with the original package.
Such a behavior is common to some types of dropper programs, which will download the malware later while not making code changes that will be detected. Sometimes anti-virus programs find the new bad stuff before it runs, and sometimes they don't.
Unfortunately, it is also typical of false positives, given the huge complexity of virus detection lists.
In my own case, running EasyPal would create a zip file named loop.zip, which Norton would "quarantine" as containing a rare Trojan which logs keystrokes and steals all your passwords. I would delete the zip archive, but it would reappear on every subsequent running of EasyPal.
The suspect file inside loop.zip is called loop.dll. Searches show one old (~2008) reference to a QRZ forum thread mentioning a file with this name associated with ham radio software. Perhaps it creates a local loopback so a simplex sound card can feed multiple programs.
There is no other mention of this file anywhere detectable on Google, and a full disk search of my computer (which has at least 30 ham radio programs), finds nothing.
Therefore, there are two main possibilities:
1. Norton is confusing loop.dll with loop.exe, a program dropped by many Trojan loaders to capture keystrokes.
2. Norton is finding malicious code that somehow gets into the EasyPal directory hierarchy via file transfers on the air, or an infected utility which is called on the fly when pictures are viewed. (If so, this is a good reason to transfer them to Irfan View, the way DIGTRX does.)
Everyone will have to draw their own conclusion. In my own case, I am far, far from certain that there is any problem with EasyPal. I still really like it a lot. However, I won't put any version of it back on any of my computers until the issue is resolved one way or the other.
Perhaps I'm erring on the safe side, but that's what I do.
A rather spirited discussion of this subject is on QRZ. There's another on the DigiSSTV Yahoo! group.
The areas of agreement are as follows:
1. EasyPal detects as clear of malware on all checkers when its files are scanned on first installation.
2. At some point after the first picture is viewed, various different virus checkers start to show various different Trojan loaders in EasyPal's directories. MalwareBytes seems to do this the most often. (There is no agreement on whether or not these are false positives.)
3. After this detection, EasyPal still shows as clear. The alleged virus is in a more recently created file that was not distributed with the original package.
Such a behavior is common to some types of dropper programs, which will download the malware later while not making code changes that will be detected. Sometimes anti-virus programs find the new bad stuff before it runs, and sometimes they don't.
Unfortunately, it is also typical of false positives, given the huge complexity of virus detection lists.
In my own case, running EasyPal would create a zip file named loop.zip, which Norton would "quarantine" as containing a rare Trojan which logs keystrokes and steals all your passwords. I would delete the zip archive, but it would reappear on every subsequent running of EasyPal.
The suspect file inside loop.zip is called loop.dll. Searches show one old (~2008) reference to a QRZ forum thread mentioning a file with this name associated with ham radio software. Perhaps it creates a local loopback so a simplex sound card can feed multiple programs.
There is no other mention of this file anywhere detectable on Google, and a full disk search of my computer (which has at least 30 ham radio programs), finds nothing.
Therefore, there are two main possibilities:
1. Norton is confusing loop.dll with loop.exe, a program dropped by many Trojan loaders to capture keystrokes.
2. Norton is finding malicious code that somehow gets into the EasyPal directory hierarchy via file transfers on the air, or an infected utility which is called on the fly when pictures are viewed. (If so, this is a good reason to transfer them to Irfan View, the way DIGTRX does.)
Everyone will have to draw their own conclusion. In my own case, I am far, far from certain that there is any problem with EasyPal. I still really like it a lot. However, I won't put any version of it back on any of my computers until the issue is resolved one way or the other.
Perhaps I'm erring on the safe side, but that's what I do.
Thursday, July 17, 2008
"Digital" Mode of the Week: Slow-Scan TV
Like HF FAX, the rather misnamed "Slow Scan Television" mode is actually analog. However, it appears in most multimode packages intended for digital reception, and it is also one of the more fun things you can do with a radio and a computer.
I can't imagine anyone actually using SSTV to send continuous video frames, though the simpler black and white versions would at least be able to do a couple of these per minute rather than a couple of minutes per frame. The major use for SSTV is for amateurs to swap still photos. In fact, I can't think of any commercial applications for the SSTV mode on the radio. The closest would be the pictures sometimes sent down by ham radios on the International Space Station.
Old B/W SSTV was a kind of scaled-down (320x240), sped-up version of FAX. It, too, used frequency or audio-frequency modulation of a single carrier or tone over 800 Hz, with black at 1500 and white at 2300. For digital, the grey scale is quantized to 256 levels (8 bits), which are plenty.
One of the first innovations was to add color. This was first done by sending the three color channels sequentially in full frame. This didn't show the true colors until all three frames were received, a rather slow process. A later innovation was line-sequential mode. It typically sends each line three times, with one 1200-Hz, 5-ms, sync pulse at the start of the red line.
One of the early color modes was Robot, as originally done in dedicated hardware boxes with a huge "ROBOT" logo on the front. It really looked like something from science fiction, and cost like it too.
Out of the 30-some common SSTV modes still in existence, nearly all transmissions are in Martin 1 (114 sec for a 320x256 frame), Martin 2 (58 sec), Scottie 1 (110 sec), Scottie 2 (71 sec), and Scottie DX (268 sec). Martin 1 and 2 were developed by amateur Martin Emmerson, G3OQD, and they are common in Europe. Scottie was developed by another British ham, Eddie ("Scottie") Murphy, GM3SBC. Its modes are dominant in the United States and Japan.
SSTV can be tuned the same way as FAX, by centering the audio between the high and low lines on the computer display. It's trickier, but you can also center the sync pulse as close to 1200 as you can get it. Most programs have AFC if you're off a few hertz. The little picture will start to scan down its part of the screen. One of the nice things about most analog transfer modes is you can start in the middle, and that's possible here too.
SSTV software can auto-start, and also it can auto-mode, either by measuring the interval between sync pulses or reading a start burst called a VIS signal. The VIS consists of a 1200-Hz marker followed by a mode designator in FSK between 1100 and 1300 Hz. A similar optional code is sent at the end of a picture.
SSTV, like FAX, will be slanted proportional to the difference between your clock frequency and that of the sending station. Various programs cope with slant correction in various ways, usually by buffering the picture and allowing its adjustment in real time during reception. This can be manual or automatic. One program, MMSSTV, allows you to click on a happy face when you get a straight picture from a "trusted" station, locking in this correction.
By far the most active SSTV frequency is 14230 kHz USB, which really lights up on weekends, going also to 14228 when there's QRM. When 20 dies, there's lesser activity on 7171 kHz LSB, +/- a kHz or so. There's also spotty activity on 6 and 2 meter VHF. Oh, and some parts of the world have pirate SSTV networks outside the amateur bands, which exchange pictures that are far more X-rated than anything amateurs can get away with.
You might have heard of the even more misnamed "digital SSTV." It uses file transfer software to exchange data, which in this case just happens to be pictures. It's typically on 14233 kHz USB, using one particular, rather fussy and esoteric program. It looks great, but it requires a very high signal to noise and almost no fading.
One of the programs designed for this purpose is the same DIGTRX that the Cuban SK01 numbers station uses to send its weird little files. Woe betide any ham who transmits with this one on 14233, though, since it is not the OFFICIAL program mentioned above. You'll think you had a visit from the Wouff Hong. Don't hate ham radio, just come back to good old grungy noisy easy and fun analog.
I can't imagine anyone actually using SSTV to send continuous video frames, though the simpler black and white versions would at least be able to do a couple of these per minute rather than a couple of minutes per frame. The major use for SSTV is for amateurs to swap still photos. In fact, I can't think of any commercial applications for the SSTV mode on the radio. The closest would be the pictures sometimes sent down by ham radios on the International Space Station.
Old B/W SSTV was a kind of scaled-down (320x240), sped-up version of FAX. It, too, used frequency or audio-frequency modulation of a single carrier or tone over 800 Hz, with black at 1500 and white at 2300. For digital, the grey scale is quantized to 256 levels (8 bits), which are plenty.
One of the first innovations was to add color. This was first done by sending the three color channels sequentially in full frame. This didn't show the true colors until all three frames were received, a rather slow process. A later innovation was line-sequential mode. It typically sends each line three times, with one 1200-Hz, 5-ms, sync pulse at the start of the red line.
One of the early color modes was Robot, as originally done in dedicated hardware boxes with a huge "ROBOT" logo on the front. It really looked like something from science fiction, and cost like it too.
Out of the 30-some common SSTV modes still in existence, nearly all transmissions are in Martin 1 (114 sec for a 320x256 frame), Martin 2 (58 sec), Scottie 1 (110 sec), Scottie 2 (71 sec), and Scottie DX (268 sec). Martin 1 and 2 were developed by amateur Martin Emmerson, G3OQD, and they are common in Europe. Scottie was developed by another British ham, Eddie ("Scottie") Murphy, GM3SBC. Its modes are dominant in the United States and Japan.
SSTV can be tuned the same way as FAX, by centering the audio between the high and low lines on the computer display. It's trickier, but you can also center the sync pulse as close to 1200 as you can get it. Most programs have AFC if you're off a few hertz. The little picture will start to scan down its part of the screen. One of the nice things about most analog transfer modes is you can start in the middle, and that's possible here too.
SSTV software can auto-start, and also it can auto-mode, either by measuring the interval between sync pulses or reading a start burst called a VIS signal. The VIS consists of a 1200-Hz marker followed by a mode designator in FSK between 1100 and 1300 Hz. A similar optional code is sent at the end of a picture.
SSTV, like FAX, will be slanted proportional to the difference between your clock frequency and that of the sending station. Various programs cope with slant correction in various ways, usually by buffering the picture and allowing its adjustment in real time during reception. This can be manual or automatic. One program, MMSSTV, allows you to click on a happy face when you get a straight picture from a "trusted" station, locking in this correction.
By far the most active SSTV frequency is 14230 kHz USB, which really lights up on weekends, going also to 14228 when there's QRM. When 20 dies, there's lesser activity on 7171 kHz LSB, +/- a kHz or so. There's also spotty activity on 6 and 2 meter VHF. Oh, and some parts of the world have pirate SSTV networks outside the amateur bands, which exchange pictures that are far more X-rated than anything amateurs can get away with.
You might have heard of the even more misnamed "digital SSTV." It uses file transfer software to exchange data, which in this case just happens to be pictures. It's typically on 14233 kHz USB, using one particular, rather fussy and esoteric program. It looks great, but it requires a very high signal to noise and almost no fading.
One of the programs designed for this purpose is the same DIGTRX that the Cuban SK01 numbers station uses to send its weird little files. Woe betide any ham who transmits with this one on 14233, though, since it is not the OFFICIAL program mentioned above. You'll think you had a visit from the Wouff Hong. Don't hate ham radio, just come back to good old grungy noisy easy and fun analog.
Sunday, April 08, 2007
Bad Dream
I keep trying to like Digital Radio Mondiale. A couple of broadcasts are pretty loud into The Land That Shortwave Forgot aka California. They sound really cool. They don't use IBOC, so there's no analog signal at all. It sounds like the old SELSCAN tones they used to use on the COTHEN net, only more so.
Good ute DXers refuse to be told they cannot extract intelligence from every weird noise out there, so of course I went looking to see what I'd need to hear the digital quality audio on my own little short wave radio. I found out that what I'd need is to modify the radio to send a 12 MHz IF directly to the computer. No thanks. I like my NRD-545 the way it is. Thank you.
If it is true that the implementation of DRM that the industry intends to use is completely incompatible, and there will never be a US $29.95 converter board for analog receivers that can be installed with two wires and an AA battery, we have a problem. Every short wave receiver in the world may someday be useless. This bodes ill for the future of the medium, since the installed receiver base in places like Africa is all that keeps it alive. People who use wind-up radios because they cannot afford batteries are not going to afford new radios either. Bye bye shortwave broadcasting.
And then, of course, there is digital SSTV.
I heard someone complaining on the digital SSTV frequency that he can never decode the pictures. No matter how loud the signal is, he misses segments and everything goes blooey. They asked him what program he was using, and laughed when it wasn't EasyPAL Lite, since that's all they ever use.
Since EasyPAL Lite seems to have a new version out every couple of weeks, I downloaded today's beta (literally dated 4/8), and started it up. Crash-o-rama. I guess it's improving, though. It doesn't hang the computer any more. It just tries to write to nonexistent addresses, and goes quietly.
Sometimes, I am told, things improve if you turn off hyperthreading. Unfortunately, I am very much of the old school, and will go to my grave convinced that good programmers do not ask their users to make BIOS changes. I guess that leaves Digtrx and HamDRM as the working programs, and I will have to be content with sending files to myself.
C'est le guerre.
Good ute DXers refuse to be told they cannot extract intelligence from every weird noise out there, so of course I went looking to see what I'd need to hear the digital quality audio on my own little short wave radio. I found out that what I'd need is to modify the radio to send a 12 MHz IF directly to the computer. No thanks. I like my NRD-545 the way it is. Thank you.
If it is true that the implementation of DRM that the industry intends to use is completely incompatible, and there will never be a US $29.95 converter board for analog receivers that can be installed with two wires and an AA battery, we have a problem. Every short wave receiver in the world may someday be useless. This bodes ill for the future of the medium, since the installed receiver base in places like Africa is all that keeps it alive. People who use wind-up radios because they cannot afford batteries are not going to afford new radios either. Bye bye shortwave broadcasting.
And then, of course, there is digital SSTV.
I heard someone complaining on the digital SSTV frequency that he can never decode the pictures. No matter how loud the signal is, he misses segments and everything goes blooey. They asked him what program he was using, and laughed when it wasn't EasyPAL Lite, since that's all they ever use.
Since EasyPAL Lite seems to have a new version out every couple of weeks, I downloaded today's beta (literally dated 4/8), and started it up. Crash-o-rama. I guess it's improving, though. It doesn't hang the computer any more. It just tries to write to nonexistent addresses, and goes quietly.
Sometimes, I am told, things improve if you turn off hyperthreading. Unfortunately, I am very much of the old school, and will go to my grave convinced that good programmers do not ask their users to make BIOS changes. I guess that leaves Digtrx and HamDRM as the working programs, and I will have to be content with sending files to myself.
C'est le guerre.
Sunday, March 11, 2007
Digital SSTV Saga Ends
After another day of watching the grass grow, I have decided to go back to utility and leave the digital SSTV experimenters to it. I received a couple more nice pictures, with missing segments, from an amateur in Mexico, who was sending dramatic pictures of women in body paint obviously applied as some sort of art show. These were great stuff, and make me want to look around Google Images for more examples of same.
To see real content is, of course, is rather refreshing, considering the one-note samba that is American analog SSTV. You have the guy that wants us to get Jesus, the one who never met an airplane photo he didn't like, and the one with "YL" in his call who sends pictures of, uh, YLs in rather scanty clothing.
Come to think of it, that third guy can keep on with what he's doing. That scanty clothing thing is fine with me.
Must... think... about... radio... .
Digital SSTV, of course, is not a very good name for it. Digital file transfer would be better, since that's what's going on, and the data could really be just about anything. That's the advantage and disadvantage.
The advantage is that, if everything is received, you have the same file that left the transmitting station, not a grungy decode of a scan of its contents. The disadvantage is that Digital Radio Mondiale in its present state is an audio broadcast mode, and better ways exist to transfer files. There is no repeat procedure for missing information transfer units (packets, segments, whatever), because in audio broadcasting there does not need to be. Segments failing the CRC check are simply discarded, and you don't hear that part.
Of course, the receiving station of a file transfer can always ask for, and get, the missed segments. They've sort of automated this process, with bad segments being logged and requested manually by clicking a button for a "BSR" (Bad Segment Resend?) transmission. This is fine, but obviously the retransmission will probably not be the same segments that people listening on-channel missed. For that, you need redundancy, like in FEC mode. In digital SSTV, real redundancy consists of transmitting the whole file more than once, but that means very long transfer times.
There is also the problem that DRM might not be the best mode for amateur equipment, which at least in the US is not allowed to exceed 1500 watts peak envelope output power. DRM's peak to average ratio is awesome, something on the order of 10 dB. In amateur service, this means that your typical 1500 watt PEP linear cranked to the max will be reading about 120-130 average watts at "full legal output."
Somehow I doubt that we will be seeing whole screens of Internet SSTV widgets showing reception worldwide, as we've had in the analog mode for some time now. (A great one is Worldwide SSTV Cams.)
Now, back to utilities...
To see real content is, of course, is rather refreshing, considering the one-note samba that is American analog SSTV. You have the guy that wants us to get Jesus, the one who never met an airplane photo he didn't like, and the one with "YL" in his call who sends pictures of, uh, YLs in rather scanty clothing.
Come to think of it, that third guy can keep on with what he's doing. That scanty clothing thing is fine with me.
Must... think... about... radio... .
Digital SSTV, of course, is not a very good name for it. Digital file transfer would be better, since that's what's going on, and the data could really be just about anything. That's the advantage and disadvantage.
The advantage is that, if everything is received, you have the same file that left the transmitting station, not a grungy decode of a scan of its contents. The disadvantage is that Digital Radio Mondiale in its present state is an audio broadcast mode, and better ways exist to transfer files. There is no repeat procedure for missing information transfer units (packets, segments, whatever), because in audio broadcasting there does not need to be. Segments failing the CRC check are simply discarded, and you don't hear that part.
Of course, the receiving station of a file transfer can always ask for, and get, the missed segments. They've sort of automated this process, with bad segments being logged and requested manually by clicking a button for a "BSR" (Bad Segment Resend?) transmission. This is fine, but obviously the retransmission will probably not be the same segments that people listening on-channel missed. For that, you need redundancy, like in FEC mode. In digital SSTV, real redundancy consists of transmitting the whole file more than once, but that means very long transfer times.
There is also the problem that DRM might not be the best mode for amateur equipment, which at least in the US is not allowed to exceed 1500 watts peak envelope output power. DRM's peak to average ratio is awesome, something on the order of 10 dB. In amateur service, this means that your typical 1500 watt PEP linear cranked to the max will be reading about 120-130 average watts at "full legal output."
Somehow I doubt that we will be seeing whole screens of Internet SSTV widgets showing reception worldwide, as we've had in the analog mode for some time now. (A great one is Worldwide SSTV Cams.)
Now, back to utilities...
Friday, March 09, 2007
MY FIRST PICTURES!!!!!!
Two days of sitting at the receiver have been rewarded. At 2226 UTC today, W9CY sent a file named UP7.jp2. Amazingly, something appeared in my rx window. I darn near spit my coffee all over the keyboard.
Here is NV6H Digital SSTV First Light:
I wonder what it is. Looks a bit like a Chrysler Air Raid Siren. I think there was something on the orderwire about its being in Hawaii. I missed about 20 segments. Obviously the Irfan View partial feature is working. All in all, not much worse than most of the analog SSTV ends up looking in California on the typical wire antennas used for ute DX.
A mere nine minutes later, the miracle repeated itself! Another picture appeared in my rx window! It's called dq2.jp2. I only lost 11 segments this time. Here's the awesome result, as seen on my very own computer:
This time I know what it is. Thanks to W9CY on the orderwire, I know that it is a Dairy Queen in Illinois!
Conditions seem quite good today. There is no telling what further miracles of human communication await.
UPDATE 2313UTC:
OH MY GOD! There is an AMERICAN EAGLE in my WATERFALL!
The possibilities for conceptual art are endless...........
Here is NV6H Digital SSTV First Light:
I wonder what it is. Looks a bit like a Chrysler Air Raid Siren. I think there was something on the orderwire about its being in Hawaii. I missed about 20 segments. Obviously the Irfan View partial feature is working. All in all, not much worse than most of the analog SSTV ends up looking in California on the typical wire antennas used for ute DX.
A mere nine minutes later, the miracle repeated itself! Another picture appeared in my rx window! It's called dq2.jp2. I only lost 11 segments this time. Here's the awesome result, as seen on my very own computer:
This time I know what it is. Thanks to W9CY on the orderwire, I know that it is a Dairy Queen in Illinois!
Conditions seem quite good today. There is no telling what further miracles of human communication await.
UPDATE 2313UTC:
OH MY GOD! There is an AMERICAN EAGLE in my WATERFALL!
The possibilities for conceptual art are endless...........
Digital SSTV Saga Continues
14233 remains active whenever the band is awake to propagate it.
The DRM has drifted slowly back on-channel, last one being measured at 14232.995, accounting for known receiver errors but not unknown computer clock ones.
One file received toward the end of the UTC day, when signal strengths tend to peak on 20, was reported as received perfectly - no bad segments, no CRC errors, full file integrity. It was a picture, according to the voice orderwire. Nothing happened. Irfan View did not start, DIGTRX did not display anything, and no file was saved anywhere. It is presumably in bit heaven.
Wonder what it was.
Seeking verification, I downloaded WinDRM, which worked, but no joy there either. Another try of a newer version of EasyPAL Lite crashed even harder than the last one, not even making it through its first initialization, while giving streams of errors about writing to nonexistent memory addresses before hanging altogether and being killed from Task Manager. Obviously some underlying runtime module is wrong, missing, or corrupt. Probably not EasyPAL Lite's problem, but radio is about communication, not troubleshooting your operating system.
I note from the Yahoo! group that this is not exactly the turnkey program of all time anyway.
While the quest continues, good old grungy Scottie 2 and Scottie DX look better all the time.
UPDATE 2125 UTC:
Discovered the local loop-back test mode. I am now quite good at sending jp2 files to myself. Software appears fine, and the Irfan View preview works.
Still no decodes here. Most stations are in the Midwest. As most people who live here know, short wave listening in California is often like watching grass grow.
The DRM has drifted slowly back on-channel, last one being measured at 14232.995, accounting for known receiver errors but not unknown computer clock ones.
One file received toward the end of the UTC day, when signal strengths tend to peak on 20, was reported as received perfectly - no bad segments, no CRC errors, full file integrity. It was a picture, according to the voice orderwire. Nothing happened. Irfan View did not start, DIGTRX did not display anything, and no file was saved anywhere. It is presumably in bit heaven.
Wonder what it was.
Seeking verification, I downloaded WinDRM, which worked, but no joy there either. Another try of a newer version of EasyPAL Lite crashed even harder than the last one, not even making it through its first initialization, while giving streams of errors about writing to nonexistent memory addresses before hanging altogether and being killed from Task Manager. Obviously some underlying runtime module is wrong, missing, or corrupt. Probably not EasyPAL Lite's problem, but radio is about communication, not troubleshooting your operating system.
I note from the Yahoo! group that this is not exactly the turnkey program of all time anyway.
While the quest continues, good old grungy Scottie 2 and Scottie DX look better all the time.
UPDATE 2125 UTC:
Discovered the local loop-back test mode. I am now quite good at sending jp2 files to myself. Software appears fine, and the Irfan View preview works.
Still no decodes here. Most stations are in the Midwest. As most people who live here know, short wave listening in California is often like watching grass grow.
Thursday, March 08, 2007
20 Meter Digital SSTV Continues
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.
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.
Wednesday, March 07, 2007
More Ham Funny Noises (This time 20M and legal)
I was trying to track down this weird noise on 20 meters. It sounded a bit like STANAG 4285, a bit like MT63, and at times a whole lot like the backscatter radar. It seemed to be centered around 14233.3 kHz. SkySweeper wouldn't do anything with it, and MultiPSK wouldn't do anything with it.
So I'm watching it on the waterfall, trying to figure out the mode - pilot tones followed by multitone 8PSK - and just then a stronger transmission started up. Here's what appeared on the waterfall:
That's right. There was writing in the waterfall, transmitted by just the right modulation of the signal. (This, in fact, is what sounds like the backscatter radar.)
See something new every day.
Other bursts had different amateur callsigns, signal reports, roger/no copy messages, and finally a smeary little identifier of a program named DIGTRX 3.11.
Google is a wonderful thing. I grabbed DIGTRX and ran it, and found out it's a digital file transfer mode popular with amateurs in South America to send SSTV pictures without the analog noise and grunge. That certainly explains why they were on 14233. The letters are called a "waterfall message," and there are also "waterfall pictures." Yes, real monochrome photos, in the waterfall. Little faxes, sort of. This is all just too cool.
Can't wait to get some amateur signals loud enough to decode the content. Terrestrial radio survives because people keep re-inventing it.
So I'm watching it on the waterfall, trying to figure out the mode - pilot tones followed by multitone 8PSK - and just then a stronger transmission started up. Here's what appeared on the waterfall:
That's right. There was writing in the waterfall, transmitted by just the right modulation of the signal. (This, in fact, is what sounds like the backscatter radar.)
See something new every day.
Other bursts had different amateur callsigns, signal reports, roger/no copy messages, and finally a smeary little identifier of a program named DIGTRX 3.11.
Google is a wonderful thing. I grabbed DIGTRX and ran it, and found out it's a digital file transfer mode popular with amateurs in South America to send SSTV pictures without the analog noise and grunge. That certainly explains why they were on 14233. The letters are called a "waterfall message," and there are also "waterfall pictures." Yes, real monochrome photos, in the waterfall. Little faxes, sort of. This is all just too cool.
Can't wait to get some amateur signals loud enough to decode the content. Terrestrial radio survives because people keep re-inventing it.
Subscribe to:
Posts (Atom)