USB Audio Input causing cyclic static noise every 3 seconds when sending tune tone from PC

[Jmelz]

I did some testing with fldigi, and wsjtx both on latest firmware from yesterday. This issue may be present or not in earlier firmwares.

Issue is that when producing a tone to tune from a PC over the usb cable for usb audio, a cycling static burst can be heard every 3 seconds or so. This behavior is not present when using analog audio inputs on the radio from a PC's headphone jack.

Not sure if issue is with driver or something else. Easy to reproduce, and happens on all bands/frequencies.

USB audio output on radio is working fine; I can actually use this for better results than the analog output (shows more detail in waterfall of pc apps).

[db4ple]

Where does it cause static noise? On the transmitted output? It is most likely existing in earlier firmwares if it is caused by the timing difference between the PC USB side and the mcHF Audio Side. If the 48khz clock of the PC differs too much from the 48khz of the mcHF side, after a while a too large difference is built up (typically if the PC is a bit slower). then at some point the buffer on mcHF side is empty and we have "silence" until the buffer is filled a little. Since the timing difference is fairly stable, you see this every 3 seconds. Due to the sharp switch off, you get a lot of "noise" generated at the edges. Every PC is different so some never have a problem, some only very occasionally and some more often as in your case. In SSB transmissions you will not notices this problem in most cases. To solve it, we would have to implement an adaptive rate driver, which fixes the time difference by inserting or dropping data when necessary. The mcHF only does the "drop" if too much data, not the inject if not enough data.

[Jmelz]

Thanks first and foremost for all of your hard work on this project, It is very much appreciated.

As far as the static noise - yes, it is on the transmitted output. The noise does not seem present on the PC, but it is hard to tell since it is a USB sound card. I can only use the PC soundcard for analog to listen (which works fine anyway).

I noticed that many people were simply trying USB for contacts, as a "proof of concept" but I don't see many people that actually had successful QSOs which would make sense; if it appears to be working and you don't listen on the receiving end, you'd miss this sound.

I am using a Microsoft Surface Pro 3 tablet. I will try with another PC as well, just for the sake of testing.

[db4ple]

BTW, if the cause is the above mentioned clock speed difference this is not strictly a bug. For precise oscillators on both side, this is not an issue. It is more an improvement I would say. You can try to fix this in hardware by adjusting the mcHF main XO (the 16 Mhz one) to better match the PC data rate. If I calculated correctly (no guarantees given), 3 seconds equal 0.13% clock difference. This is a lot.

[Jmelz]

Is this a software setting?

[db4ple]

Well, PSK31 QSOs and RTTY are done via USB audo. Voice of course is the exception.

[Jmelz]

Yes, I understood what you meant :)

[db4ple]

No. Unfortunately not a software setting.

[Jmelz]

So far on the other PC, I thought it was good, but I hear it there as well. However, on this other PC the time between "static bursts" is more like 7 seconds.

What brought this to my attention, was specifically trying to use WSPR - the long transmissions were not being heard by receiving stations. It was a late night of testing :)

Even with the 7 second blip on the other PC, I was able to make a successful WSPR transmission that was heard. 5w signal went 3600 miles.

[db4ple]

WSPR is very agnostic to this kind of problem. The faster digital modes without error correction such as RTTY or PSKxx might be more affected by this but we haven't had a report for that.

[Jmelz]

Sure, makes sense. I think there will be few reports by most unless they listen separately to the radio output on another radio.

I will be using many digital modes when traveling with this radio, so I'm sure I'll put it through the test.

I hope a fix in the way of a driver modification is possible. Thanks again for your time.

[df8oe]

Can this be closed now?

[Jmelz]

Was there a change since I posted? I've not tried latest software.

[df8oe]

No change in firmware - because the reason are timing differences between PC and mcHF. You have to live with that - or must look for a PC which has the same approach to 48KHz than mcHF. You will not eliminate the efect - but widely reduce. There is no solution actually - so this is a "known and not removeable issue".

[db4ple]

Hi, nothing has changed. It is an issue (currently not very significant problem I would say) as it does not impact any of the digital modes (at least we haven't heard about this). So we should put this on the LATER list.

[Jmelz]

I think many are using ft8 and probably not yet the other modes. I'm going to solicit info via the Facebook group. I think more would notice the bug if they had another radio to listen in on their own digital transmissions.

[isenburg]

Making QSOs in FT8 works fine. However I do noticed that problem while using the tune function of fldigi too. (Firmware 2.5.130)

[Jmelz]

Any chance this priority can be raised? It's a bummer that one of the biggest features of the radio (usb audio) is not usable on many digital modes because the radio is making noises (due to a bad software driver that could be fixed) :(

[db4ple]

If it could be fixed easily we would have done it already. I can assure you of that fact However, it is by no means trivial and we have not yet a working solution. Anyone with experience on implementing such an adaptive rate audio driver is invited to contribute a solution.

[Jmelz]

Thanks - I understand it may not be a simple task - and I hope I do not come across as demanding. I really do appreciate all of the efforts made with this radio. I was just hoping that the issue is not seen as a minor tiny problem - as it is marked very low priority, and maybe is not getting any attention at all (as such). I figured if priority was raised, maybe it would get more attention.

[DD4WH]

That could probably be done by a fractional resampler (not totally sure), which means you would have to know both sample rates (mcHF/OVI40 and your PC/laptop) very accurately in order to tell the resampler which difference in sample rates there is. But how would you know the accurate sample rates without measuring them? And a fractional resampler is not at all easy to implement and would probably not run on slower hardware (mcHF). Second possibility would be the one Danilo mentioned: to insert audio snippets, but would that help for digital modes? I am not sure. If anybody with programming skills can help with that problem, go ahead!

[sp9bsl]

Hi, this is very complicated matter, not reachable on F4 core when it does so many things in parallel, you may read some in the AD1893 datasheet. I've tried this in s/pdif recever and it worked but not as good like cheap ic from Analog Devices, anyway it used a lot of resources of the STM32F4 core...

[df8oe]

I set priority to "low" because of two reasons. The second one is that I do not see (as all other programmers) how to solve this. Maybe it is impossible on F4 with "radio function" in background. But the first and much more important is that I am using digital modes and USB audio intensively and I do not see any issue! I can work SSTV, WSJTX, RTTY without any malfunction. OK - I have not tested sending a TUNE tone via USB to radio. But that is a function I never need. I am sending digital data and there are no decoding gaps on receiving machines.

[Jmelz]

hi df80e, The issue is not related to Tune. The issue is related to all USB audio period...

If you listen to the transmission, you will hear small gaps of static, just as I described. More robust modes can make up for this lack of consistency, but other modes just as JT9 will have issues.

[db4ple]

Hi, I can assure you that JT9 works well This summer I did a number of QSOs in this mode without problems.

73 Danilo

[Jmelz]

hi db4ple - while I don't doubt that at all - have you listened to your output? I can make a recording if I am all alone in experiencing this...

I'm not saying jt9 won't work, just that for weaker reception areas - this will impact decoding.

[isenburg]

My mcHF has the same cyclic static noise but I am able to make WSJTx, JT9, PSK and RTTY QSOs...

Am 03.01.2018 um 21:12 schrieb Jmelz notifications@github.com:

hi db4ple - while I don't doubt that at all - have you listened to your output? I can make a recording if I am all alone in experiencing this...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/df8oe/UHSDR/issues/1077#issuecomment-355114480, or mute the thread https://github.com/notifications/unsubscribe-auth/AC_Wkow1J1gVs8Pbw_frGMWgqyWyTRfsks5tG99AgaJpZM4PZO26.

[db4ple]

As I said above, the problem is known but not solved. Due to different frequency difference the problem is more or less frequent. No need for a recording from my point of view.

[Jmelz]

Okay, understood. I was thinking from your comment that you were saying you did not see the issue at all.

Thanks.

[DD4WH]

If I try to summarize all the comments made here correctly, there are the following points to mention:

1. we have identified a problem
2. the solution to that problem is very complicated and time-consuming to program and would only be able to run successfully on machines with a fast processor (F7/H7)
3. there is not a single report of a systematical test, that would give evidence that the known problem is causing any trouble at all in digital mode reception. But maybe I have missed a report on that?

So, I would propose to spend our programming time on more urgent issues. Jmelz, I really appreciate your bug reports and observation! We need this kind of information and please continue to report such things. But I believe that in this case, we have to say: leave as is, unless we really have a huge amount of spare time or somebody has a more intelligent solution to this problem. If the latter should be the case, please go ahead! ;-)

All the best, have fun with the UHSDR software!

Frank DD4WH

[Jmelz]

Hey DD4WH - I think that sums it up, and I appreciate your comments. However, on 3 - I can easily reproduce the issue with a tone test, and I do have problems with reception of my transmissions on digital modes. I can go to a pc with a different radio and transmit and be decoded with WSPR, and go to the MCHF and not be decoded. That's the easiest way to duplicate the test.

[DD4WH]

We do not need to talk away the issue, it is there, that is for sure. The question of interest is: does it matter?!

Could you go into more detail with your test?

• are you transmitting with the same power amp hardware? that would be one prerequisite for a valid comparison

[Jmelz]

Hi DD4WH, I know it might seem apples to oranges, but yes, I am transmitting at 10w with both radios. Sometimes I've done with 5w as well. I don't think that the test details really matter too much, as this looks like something too complicated to fix. Shame - as I cannot reliably use the USB port for audio and long distance QSOs if it will not perform as well as my old 857d. I understand that this is complex, but I guess I thought that this was a unique selling point for the radio when I got it. It took several failed transmissions before I realized that this issue existed. When I changed PCs and hooked the MCHF to another PC, I saw that the experience improved from 3 seconds to 7 seconds. However, the one where it happens at 3 seconds is my primary ham radio PC - a windows tablet.

[DD4WH]

yes, it seems you are comparing apples to oranges . . . and unless the test is being made with equal hardware the question "does it matter" is still not answered. So you cannot be sure of your conclusions.

"unique selling point" --> I am not selling anything, the UHSDR is a project where volunteers are adding features to the software in their free time . . . :-)

[Jmelz]

I'm using same PC with two different radios. One has an issue with audio, one does not. I am not looking to argue about it. I know it happens, others have seen it. I get that it is a complex issue to fix, but I bought the radio personally because of the great community around it and features such as this. It caused me to not have the same performance as my other radios. I'm sure of the problem existing. I am sorry if you mistook my comment about selling - I meant it simply that I bought the radio with a set of features, and realized later, that one of the biggest features I wanted it for, is not working as well as every other radio I own. Sort of a bummer. Oh well.

I do appreciate all of the efforts. I am involved in many projects - doing beta testing, and it is not lost on me that this is a volunteer effort.

[df8oe]

I want to add a different definition:

May be that there is such a cycling noise.

But this does not impact anyone of the digital modes I am working with (and I am working digital modes)! So there may be a problem, but that does not cause any issue in working for me. Modes like JT9 and JT65 are designed to work with a very low S/N ratio. So they do work with much more noise (and yes: included cycling noise) flawlessly.

So I call this a "minor bug" which has "low priority".

Does not impact working, is only "cosmetical." There is not one single additional report of "digital modes do not work" but yours... I do not think others do not use digital modes or do not report such a major bug (if it is one).

If you do have impacts on working with digital modes there must be another issue that rises up we do not have here. The noise you observed seems to do no impact on function.

[DG9BFC]

does this noise on every few seconds also happen when transmitting an sstv picture and also when sending psk31?? when the noise does break a letter in a psk31 qso it will not matter much (a noise burst on the air would do the same) ... but should we not try to send error free data (before band noise adds)?? a missimg letter in psk31 qso does not hurt ... a bad pixel or two in an sstv picture also does not matter much ... and all ow s/n ratio modes will also work fine WITH these noise bursts added when you send psk31 from mchf direct (not from pc) ... is then the audio clean?!? dg9bfc sigi ps a small trimmer cap to the 16megs xtal is the last option i guess

[db4ple]

Hi Sigi, the problem is that on BOTH sides the frequency is not exactly 48000 and the frequency changes with temperature changes (on both sides). And even worse, on the mcHF the configured frequency is not even 48000 to start with (that has to do with how the various clocks work, maybe a valid combination of the various multipliers and divider exists to deliver theoretically 48000. But the divergence of frequencies still remains as a challenge (not as big but still it will be there). It is a problem the software side has to fix, not the hardware side.