Increasing Audio Quality
Is there any chance Audio quality can be increased ? there's a big difference listening to a SDR such as Airspy or SDRplay, I know this is necessary for bandwidth reasons but could a several quality options be implemented rather than say low or high ? then the owner can decide based on their bandwidth available.
Comments
If by 'quality' you mean how it sounds then you could try turning off audio compression ('comp' button on audio tab) and see if you hear any difference.
Or are you talking about bandwidth larger than the current 12 kHz max?
Higher quality/fidelity.
Options like 16 Kbps, 32 kbps, 64 Kbps, 32000 sampling rate, 44100 etc.
A different Audio CODEC ?
I noticed on the SDRplay and Airsipy that the higher audio quality makes a difference to a copy of a DX station sometimes the difference between legibility and not, I understand completely that having the bandwidth of USB can't compare but it would be great if audio quality could be increased and it would make listening in noisy conditions less fatiguing.
What do you think ?
I have my 2nd Kiwi ordered and Linear PSU on the way :-)
but i do realize that there is alot of changes that must be made to the code in order to make this work plus, this change may push the hardware to its limit but a work-around may be to use only 4RX channels instead of 8RX channels.
i would gladly sacrifice the additional RX channels to provide high fidelity AM/SSB audio since there are many transmissions that exist (like SWBC stations) where 10Khz audio is being used.
Heck, I can't even hear 4 kHz any longer!
Glenn n6gn
i have considered changing parameters within the "kiwi.config" file, specifically this entry:
// rx // don't forget to redo the CIC filter compensation when SND_RATE changed DEFp SND_RATE 12000 DEFp RX1_DECIM 505 // to get near 12000 for integer WSPR sample rate DEFp RX2_DECIM 11 // 505*11 = 5555, 66.6666M/5555 = 12001.188 Hzbut i do not know if this change will make the necessary changes for the openwebrx interface to reflect the bandwidth changes and im not comfortable at this time doing a build to find out.
it would be nice if there was some documentation available.
I think it's clear that the hardware could be made to do it but this does seem outside the original scope of the project. While one is considering changes such as this, someone else might want wide-band FM if we add VHF-microwave block converters (I'm considering this on my list of projects).
I'd say "have at it" if you like, but perhaps not a mainstream requirement.
Just my opinion.
Glenn n6gn
10Khz audio fares much better as a minimum than the maximum 6Khz audio Kiwi provides.
after all, this is the 21st century, not the 20th.
it seems to be configured for 12Khz at the hardware level (see previous post about kiwi.config).
simple confirmation from the developer that the hardware can support 20Khz bandwidth would encourage me to do the necessary code modifications but id rather not risk "bricking" or damaging the device as a result of changing the SND_RATE value in kiwi.config from 12Khz to 20Khz especially when code documentation isnt available.
It's out-of-date now but you can read about some of these issues in the design review document: https://www.dropbox.com/s/dl/i1bjyp1acghnc16/KiwiSDR.design.review.pdf
that is how i assumed it would be, as you stated it.
the question is, if i proceeded to rebuild under this chosen specification, would reducing the available RX channels to four (or less) be a sufficient trade-off to operate under the top limitation of the FPGA and associated hardware ?
thanks.
Getting greater than 12k from 4snd/4wf is a separate problem requiring a different architecture from trying to get the maximum IQ bandwidth possible from a single channel (i.e. making the Kiwi act like all other USB-based SDRs out there that use external PC-based control software).
The problem with this sort of development is that you are pushing all the soft boundaries to their absolute limit. And because there are so many competing processes for resources (e.g. GPS, extensions) you just don't know what's going to give out first. Are you going to run out of SPI bandwidth to handle the audio without dropouts with all possible loading from the GPS? What about running out of cycles on the little eCPU on the FPGA? There are a dozen considerations like this. So you are reduced to incremental development, testing and measurement (there are some built-in realtime measurement tools to help answer some of these questions). Overall this means the total architecture has a very steep learning curve and you're unlikely to make a major change like this easily.
Why is the Kiwi like this? Is this poor engineering? No. It's because the Kiwi was designed to sell for $299/$199 yet have its unique feature set that is different from every other SDR out there. This required a huge effort in optimized/compromise engineering.
if i can rebuild this for better sound quality on AM/SSB and make some trade offs in other areas, ill do it.
the idea here is to increase the fidelity of the sound, there is a community of hobbyists that would like this for Kiwi.
if i am successful with this project, id like to share it.
Then on the target Kiwi I use NFS to mount the Mac sources read-only onto /root/Beagle_SDR_GPS. So I can just ssh into the Kiwi and build/test there without having to be copying all the source files all the time. unix_env/bashrc (that gets installed as /root/.bashrc on the Kiwi) has some hints about setting up NFS on the Kiwi and your development machine (I don't know about Windows though). Because the mount is read-only if the update process is unintentionally started on the Kiwi it won't reverse-write the sources on the Mac and destroy my work-in-progress (super important obviously).
The various Makefiles have manual targets for copying the Verilog source files to whatever environment Xilinx Vivado happens to be running. In my case I run it on Ubuntu on a VirtualBox VM on my Mac. It works surprisingly well despite all the emulation layers (about 10 minutes to build the FPGA image on a three-year-old MacBook Pro).
thanks for the advice and info jks, it is really helpful and insightful.
the more documentation and information, the better.
i have moderate to good experience with embedded devices using busybox/linux (iot's) but the Kiwi is a bit different from that aspect as well as the custom code thats written for the "project", so i need to ingest and digest as much info thats available about it aside from observing the code that is written in the project directory.
for now, i feel "safer" customizing and rebuilding the "web" directory to my liking.
Be sure to keep good backups if you're tinkering with Beagle_SDR_GPS/web. One 0200-0600Z update and everything will be wiped out unless you have automatic updates turned off.
http://64.136.200.36:8073/?f=1160.00/12000amz9
vs
http://64.136.200.36:8073/?f=1160.00/16000amz9
Remember that you can change the passband width by typing / into the frequency box (e.g. /20000 for 20 kHz). Or using the 'p' and 'P' keys.
There are some problems as expected. I used a SND_RATE of 20250 so that SND_RATE/54 = 375 so the WSPR will still work (it does). There are some audio underruns of course. But I was able to make two regular connections and a WSPR extension connection and it seemed to work okay. The GPS seemed to run fine.
I think it sounds not quite right with a bandwidth greater than about 16 kHz. That might be a problem with the re-sampler that runs in Javascript on the browser. Measurement for passband flatness is obviously needed. There seems to be some high-frequency artifacts with the compression turned off which doesn't quite make sense.
you beat me to it jks.
i think it sounds perfectly fine at 20Khz bandwidth (10Khz audio), thats the minimum standard for hi-fidelity AM/SSB.
here is an AM station that utilizes 20Khz bandwidth (10Khz audio).
http://64.136.200.36:8073/?f=610/20000amz10
i agree with eckrot, if we could get this as an option on the Admin panel if having an increase in bandwidth does affect the FPGA/BRAM/Beagle, perhaps operating at 4 RX is the trade-off to have hi-fi AM/SSB audio.
there are additional benefits with 20Khz bandwidth - DGPS decoding.
this program Amalgamated DGPS (https://www.blackcatsystems.com/software/dgps_decoding_software_sdr.html) can utilize 20Khz bandwidth much more effectively than 6Khz bandwidth to log more DGPS stations on a Kiwi.
is it possible you can share the modified source code so i can implement this ?
thanks jks ! (i knew this would work)
Kiwi will be one of the few to have hi-fidelity audio (10Khz audio minimum), many other online SDR's dont have this but i am sure a large part of the hobbyist community wants this.
If I release this as a replacement for the 12 kHz bandwidth of 4rx/4wf mode you can imagine the howls of protest. So, as you suggest, it should probably be a third FPGA mode. But more experimentation is needed to see if a less stressful configuration might stop the glitching. Perhaps a 2rx/2wf mode @ 20 kHz that is more designed for private listening by the Kiwi owner rather than multi-channel public access Kiwis (although that would still be available).
Other things to note: Because the waterfall is deliberately the lowest priority process due to its large resource requirements you'll note that it becomes painfully slow much sooner with two or more connections in 20 kHz mode. Also unknown until I check is how many places the 12 kHz bandwidth number is hardwired into code. I tried not to do this, but it may have snuck into some extension code and maybe even the kiwiclient/kiwirecorder code. This will all have to be fixed.
TDoA and GPS wouldnt really be needed to provide this listening experience though advanced users like myself can calibrate the ADC manually (if needed) and easily (zero-beat to <1Hz on separate audio waveform scope display using I/Q on WWV at 10Mhz).
perhaps additional display info for Kiwi's listed on SDR.HU that indicate the current type of Kiwi (standard/20Khz) so users can choose/avoid that Kiwi. (the user may not care for 20Khz BW) - something displayed like "Hi-Fi Audio" may work.
not all Kiwi owners may benefit with 20Khz BW but there are some who are located in better geographical areas who can benefit from this.
i dont want to make this complicated for you or anyone else; with the current hardware, its not possible to have the "best of both worlds" but to have a choice available is better than none.
i myself use a certain Kiwi to listen to certain "ambiguous" AM/SSB HF broadcasts that i cannot receive locally and often wish the BW on that Kiwi was at 20Khz.
thanks JKS for taking this into consideration.