UHSDR
UHSDR copied to clipboard
df8oe
USB Audio Input causing cyclic static noise every 3 seconds when sending tune tone from PC
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).
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.
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.
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.
Well, PSK31 QSOs and RTTY are done via USB audo. Voice of course is the exception.
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.
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.
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.
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".
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.
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.
Making QSOs in FT8 works fine. However I do noticed that problem while using the tune function of fldigi too. (Firmware 2.5.130)
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) :(
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.
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.
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!
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...
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.
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.
Hi, I can assure you that JT9 works well This summer I did a number of QSOs in this mode without problems.
73 Danilo
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.
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 [email protected]:
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.
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.
Okay, understood. I was thinking from your comment that you were saying you did not see the issue at all.
Thanks.
If I try to summarize all the comments made here correctly, there are the following points to mention:
- we have identified a problem
- 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)
- 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
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.