Aliases? [fixed in v1.649]
I've seen this before: Champ (E21EIC) is operating so high up on 30m that the oxygen masks deploy automatically thinking the shack experienced a catastropic depressurisation:
Note decode by the JTDX instance in the foreground at 22:12:00 GMT said to be from E21EIC on 10149.498 kc
Meanwhile, over on another machine also chewing on audio from 10 Mc:
Note similar-looking decode at 22:12:00 GMT by the JTDX instance in the foreground said to be from E21EIC on 10137.497 kc
I guess this might be why I copy the locals at times on frequencies where they aren't - even if they are a bit shy of pushing the ADC to all-1s... or even further it seems, as Champ wasn't tremendously loud. So what am I doing wrong now?
73, VR2BG.
Comments
Yes. I really only understood there was an aliasing problem last March when I added some tools (AF spectrum, sig gen improvements) and was working on the NBFM de-emphasis stuff.
The good news is that it doesn't have anything to do with the ADC. The bad news is that my fix for the problem is still not working. Although there is a fix and we will get there eventually.
It's a long story. But I need to add post-CIC FIR filtering to the FPGA. It's tricky because the FPGA is basically full. But I found a way to do it. I simulated it, and it works. But it doesn't work in the FPGA for some reason. I haven't had time to get back to the problem.
It's exactly as you've noted: Signals from the adjacent 12 kHz channel will get folded over into the upper part (+3 to +6 kHz) of the passband. This goes unnoticed when narrower passbands are used (default SSB and CW passbands).
A little more info. The text and image below attempt to describe what's happening.
The AF spectrum (not RF) is shown on top. Since the RF is tuned to 10 MHz the spectrum represents the -6/+6 kHz audio passband (9994 - 10006 kHz). If the sig gen were to be tuned across that range you'd get a flat line at the -80 dB level between the two red markers (note the sig gen attn is set to 80 dB and that each white AF marker is 1 kHz).
What the yellow line shows is the response when the sig gen is tuned in the next channel above, namely 10006 - 10018 kHz. 10006 to about 1009.5 is being aliased, at a decreasing slope, into the top of the passband (9994 - 9997.5) In the rest of the passband the alias is down about 50 dB.
The magenta line shows the response when a modest post-CIC FIR filter is added (one that doesn't take too many FPGA resources). The midband response is down 40 dB and the ultimate rejection is 60 dB. Remember, these are audio response numbers. So even 40 dB is pretty good.
You don't this aliasing problem at any other frequencies besides the bottom part of the channel above (into the passband LSB) and the top part of the channel below (into the USB).
But note as I mentioned in the previous post that you won't really see this problem unless using a wide passband. The problem is 30 dB down even for a 4 kHz wide LSB passband.
The other morning I see this:
And I wonder why is VR2KW so weak - and operating FT8 somewhere just south of 7049 kc?
Meanwhile, over on the other machine chewing on 7074 kc:
So it wasn't one of the recent DXpeditions that seemingly were always QRV with FT8 where normally one would expect to find FT4 - it was just VR2KW again.
Is there an award for confirming KiwiSDR aliases just from receiving off-air signals?
If so, I might have gotten a bit ahead of myself with the next one... can't be bothered at the moment to find the screengrab, but I could find the scribbles on a piece of scratch paper on the shack desk:
Spurious FT8 signal seen on: 24919 + ~1 kc
Local FT8 signal (present when spurious signal above is present) seen on: 28074 + ~2.2 kc
No wonder why I see JT-mode signals all over the bloody place - like
73, VR2BG.
That wasn't what I posted.
-VR2BG.
You should be able to edit your post at any time. Click on the "gear" icon that appears at upper right when you mouse-over the post.
Fortunately, I forgot what it was that I had typed.
It seems that when composing something here, having two large graphic images in it eventually makes my browser think it's suddenly developed life-threatening constipation & needs something done to rectify it. Everything slows down. And perhaps what's subsequently typed doesn't make it into the drafts that the saving of perhaps is what triggered the constipation detector in the first place. So when you hit "post" what gets posted differs from what you thought you were going to post.
I'm seeing aliases from my neighbours' signals greater-than 3 Mc away. Perhaps it was better that the constipation took out what I had typed as no anti-aliasing filtering at all... all along... is... ...making it hard to find the appropriate word that will not be disappeared.
-VR2BG.
So Christoph (as he usually does, lol) got me to rethink what I had been doing with the FIR filter. And I immediately realized my stupid mistake. So the fix is working.
The problem now is that a way must be found to squeeze an FIR filter onto the output of each audio channel within what little FPGA resources remain. I have a technique in mind. But it will take some time to implement and get working.
Fixed in v1.649