开云体育

Sample rate conversion artifact.? Try setting the center frequency of the bpsk31 signal to 500.



David

Hi Curt,
A couple of comments come to mind. Bear in mind, these are based on my understanding of fldigi...I'm not a dev.

1.

The picture below is with no transceiver connected -- only the output of fldigi affecting the waterfall:

...but that is always the case. fldigi can't sample what the radio is sending for several reasons. So the fldigi TX audio stream is limited to just what fldigi ~intends~ to send. In fact, fldigi can't tell what the CODEC is sending to the next device downstream. It might be some piece of hardware, such as digirig, and it might be going directly to a radio. fldigi doesn't know. So for output, what you see on the waterfall is what fldigi has composed to send.

2. What psk? Is this just a Tune tone ? Remember...this is what is sent to the radio, so there is no carrier in play here.

3.

harmonics (low level though, <-60dbc ) far away from the carrier in the waterfall when I transmit.

It looks like you are showing us the SIG display. You will see the harmonics on the FFT display. Remember, fldigi composes the waveforms digitally. Someone else will have to ring in with the details. But IRL, the audio stream consists of fldigi composing a waveform at some freq (here I mean the sampling freq, not the waterfall freq), then the CODEC in play (you mention a CODEC with "native" sampling rates; I use 48000)...those 2 will create a complex wave with an approximation of the envelope you want for the chosen modem...then any intermediate devices, and finally the radio (which I understand is not in play here).

73 Rich

Thanks for clarifying. I have seen the dropped bits with many fldigi modems. I don't know why they occur. There are several possibilities related to threading and OS not being real time. I find the signal error is usually in the same place for a set of circumstances, but does move around depending on the modem of choice and the waterfall "center freq".

Keep in mind that you are looking at what fldigi thinks it is sending the CODEC, so the SIG, FFT, and waterfall all have naught to do with anything further downstream...AFAIK. I don't think fldigi looks at the device, looks at its digitization freq (mine is set at 48kHz), and then creates a signal. I ~imagine~ that fldigi simply creates a digitized version of the sine wave it needs (actually combining them for more complex signals) and sends that to a CODEC. The CODEC takes the wave and samples it at the rate defined in the device table (Sound settings, in Windows), and sends that sampled signal to the next device. Someone on the dev team will need to correct me on that.

BTW, I also use 500 Hz or so for my "testing" when I want to look at signals.

As for the spectral artifacts...those audio sideband artifacts...good question. I assume that the SIG display and the FFT display show exactly what fldigi is producing. And there are all those "sidebands". I don't know the method or algorithm. "Filtering" an audio signal in real time is expensive. We all don't have spare FPGAs floating around our laptops. :-) So if the method for producing the signal produces audio side tones, they are transmitted. The question is...to what end? On the RX end, fldigi uses an FFT to find the real data in all the noise, so those very low signals don't "make the cut", so to speak, and don't figure into the final data for decoding what freq was the important freq. And people aren't really listening to the sidebands, are they? Even when we listen to the TX audio at the fldigi end, we focus on the part of the signal that is much "louder" than the sidebands.

We are used to thinking that the sounds are all clean audio but they aren't. If I play a piano, theoretically I can get a pure note (not IRL), but the instant I send that to a digitizing process, I change it. I have audio samples here that were recorded with NO digitizing, and the same signal sent in parallel to very expensive digitizing equipment. I can hear the difference. fldigi, the new DSP radios...they all are creating artifacts, and we just ignore them, often because we are so thrilled with what the digitizing is doing for us, such as filtering out "noise". The only way you are going to get signals without artifacts is by using analog all the way from your voice to the antenna...oops...we hams all know that's not true, right? Otherwise, why do we have an FCC spec on transmitted bandwidth? We have it because the instant we combine the audio stream with the carrier, we produce sidebands.

On 2024-09-12 16:54:, Curt Karnstedt wrote:

And when I say "carrier", I mean center frequency, understanding that no carrier is present.

Got it.

The picture of the signal scope is just transmit with no on data going out, while the spectrums are showing sending data.

Here I assume you mean that you hit TX with no data, while I usually test by hitting Tune.

73 Rich

Yep. Depends on why you are performing whatever test...
I often set up 2 or more systems to test some interoperability, and I don't want all that RF floating around. So I use hardwired systems.
But I also want something predictable, and hitting Tune gives me that. So if I want to use an independent scope, I can make sense of the waveform.
Then I can move on to send and receive tests and testing more of fl_suite, such as flmsg.

***We need to leave on the table the possibility that the artifact you are referencing in the images is ~not~ part of the output audio stream, but rather is an artifact of the fldigi display system.

To see this,
1. Set center freq to 500 Hz. Select SIG.
2. Select psk31.
3. Hit Tune, and observe waveform. Turn it off.
4. Toggle T/R. Note whether the waveform...now a composite waveform based on the modem, and ~not~ a simple sine wave at a the "center" freq...has an artifact. Keeping an eye on the SIG display, toggle T/R off. At the instant fldigi stops "transmitting nothing" using the selected modem, there will likely be a brief display of the "center" freq. If the artifact is at the same place, then it is occurring at a place in time based on the start of the SIG sweep, not the construction of the modem signal.

73 Rich NE1EE
The Dusty Key
On the banks of the Piscataqua

On 2024-09-12 23:14:, Curt Karnstedt wrote:

I took your suggestion and used File -> Audio -> TX generate to capture the waveform output. I don't see any dropped samples or glitches in the TX generated output even when I see them in the SIG display using Tune.

So that's a clue.

Another is that the glitch is fixed on the display. We don't know much about the display. I hear some questions about it regularly. I have asked in the past for the ability to customize the SIG display, but I think I am in the minority. Many hams simply don't use it. It is such a valuable tool, but it took me literally a year to convince some local hams of its value. Now they use it regularly. If we could change the time base of the SIG display, we might see the glitch disappear. Also, we don't know how the SIG display is generated...is the starting point random or does it wait for a zero-crossing? IIRC, every T/R display starts the envelope at zero, so...?

Another is that you might not see the glitch using, say, BPSK125 WF=500Hz, using T/R,
...BUT keeping those settings and using Tune might surface ~a~ glitch. You asked earlier why Dave's image didn't show the glitch, and now you have a clue. If it shows on one SIG display and not the other, it's likely a display problem. Now...why? Threading? Buffering? Task priority? We'd need to see Dave's SIG display for exactly the same conditions that we see a glitch. However, Dave did comment, without any explanation, "Sample rate conversion artifact.", nor did he mention ever seeing the glitch.

All this is why I mentioned earlier that I see the glitch regularly, if not predictably. By regularly, I mean that I don't always see it, but I often see it. It never affected fldigi performance, and when I observed received waveforms on a different system, there was never a glitch.

But how do we really know which one is actually the one that is sent to the transceiver?

I think you do know by this time. All the clues are there, including Dave's cryptic comment. It's reasonable enough for anyone with experience with waveform sampling, but I wouldn't expect the rank and file ham to have that background, and those without are unlikely to wonder. QED.

~R~

Thanks for that...nice to get another look at the situation...

On 2024-09-14 15:45:, T? via groups.io wrote:

So bottom line, I would recommend to ignore the 'signal' trace in the FLdigi Gui and keep using the waterfall, which appears to be ok for all usual intents and purposes.

I disagree with the suggestion to ignore SIG. The glitch should be identified and commented upon in the fldigi docs...or corrected. I find the SIG display very useful, and I recommend anyone continue using it, but with awareness. Now that we've had this discussion, it will be easy to overlook the glitch, but the best approach is not to have it in the first place. I find the WF, FFT, and SIG displays all have use in their ways, and I would not give up one of them.

~R~

My Windows 11 has flagged the last 2 zip files as infected with
Trojan:Script/Sabsik.TE.A!ml
I submitted the first to several online virus checkers, and no virus was found.
Makes me wonder what pattern this file contains.
Or maybe just W11 being annoying, as usual.

~R~

On 2024-09-15 09:37:, T? via groups.io wrote:

In other words, the glitch positions are independent from the frequency or signal pattern!

Yes...we observed that earlier.

3. While I had initially assumed the glitches may be linked to some sort of signal clipping, in fact they are not, since they do appear at any amplitude

Agrees with earlier observations.

Very nice summary and eval. I havna looked at the zip file contents yet.

73 Rich NE1EE
The Dusty Key
On the banks of the Piscataqua

On 2024-09-15 10:24:, T? via groups.io wrote:

Rich,
I always check any file I attach using the official M-Soft System Endpoint Protecton with updated definitions, so I must assume they are clean.

I assumed they are clean after several non-MS checkers all agreed they are clean. I tried to submit it to MS, but I needed to login, so skipped that step. In retrospect, I don't think it will do any good anyway. Defender would simply add that specific file to its exception list, and prolly not figure out why it thinks there is a virus. But Defender quarantined both files immediately upon receipt for the same virus, so there must be some pattern that Defender is finding...I can't imagine that MS would simply quarantine ANY zip file from email, and then make up a virus name. So, your files are OK by me. I was just letting folks know that W11 has a problem with them, and a dozen other services don't.

~R~