Today I fixed a desync problem that arised when the network stutters, leading to a waterfall ahead of the audio. In the worst cases it meant a several seconds delay.
Then I stopped using the default Monospaced font (that depends on what you have installed!) and added the Terminus font that I really like for readability and style. I also reworked a bit the size to be easier on the eyes. Hope it helps!
Other improvements:
several rapidly changing numbers such as the s-meter value and the waterfall top and bottom values in dBm are now updated just once a second;
the audio panning for each RX is now selectable in steps: left, center-left, center, center-right, right that are represented as <<, <, ^, >, >>;
the help window is now in sync with the new features.
This version is only available from the git dev branch, the others will have to wait a bit, as usual...
KiwiSDR offline or under maintenance! Failed to connect!
I have the following questions regarding the networking protocol and the claimed low latency: Does supersdr receive IQ for the whole waterfall and calculate the waterfall + demodulated audio from it, or does it receive processed waterfall data + demodulated audio the same way the Web based front end does? If supersdr receives the same data as the Web based front end, then I wonder why supersdr claims much lower latency than the Web based front end.
I have to add a lot of buffering (hence latency) with the KiwiSDR UI due to the large amount of jitter and scheduling delay present when playing audio through all the different browsers/device combinations.
This uncertainty is not present with SuperSDR since no browser is involved. But of course there are trade-offs (software installation being the most significant one I would say).
Although probably caused by the Pulseaudio in my Linux desktop, I have no issue with audio via the Browser and Kiwi web based UI but with SuperSDR I have an underrun problem. I do not have that problem on other boxes. So there is a good example of the Kiwi's buffer helping.
as John wrote above, I do exactly as the standard web UI, but you can reduce the latency a lot by using the runtime option -b 1 if the kiwi you're connecting to has a fast internet connection or is in your local network. I can use Kiwis on the other side of the world with that setting and I only rarely have problems. The default buffering is 10 or 15, I don't remember.
Regarding your error, I believe that the kiwi to which you were connecting was upgrading the software, or it's set as "private". Usually the status should be "active".
You may download the latest version 3.13 with several updates from the the github page as usual.
Trying out the 3.12 Windows(10) version.... it doesn't seem to find my local kiwi so typing in the ip/port everytime is a hassle. Same with other KIWI's, I was hoping it would store those for quicker access next time - maybe it does but I haven't found the secret yet.
The other comment is the delay in the audio stream is huge. The waterfall seems quick but the audio delay is perhaps 10 seconds or more. The regular KIWI software is much quicker on the same machine. Something else I haven't found the secret to?
Thanks for any insight and for making the program available.
but you can see all command line options by running supersdr.exe --help
You may avoid the -P and -w and it will just use the default 8073 and no password.
Alternatively, create a file with a text editor called kiwi.list with these lines:
KIWIHOST;KIWIPORT;KIWIPASSWORD;COMMENTS
192.168.1.82;8073;;my super kiwi receiver
Once you create the file you can add other KiwiSDRs by pressing q within the program. There you can just connect or save the new server to file and connect. The first line in the file gets ignored, so either you manually create the file or, within the program, save a first fake server (it will be seen as a comment line) and then the server(s) you want.
The delay in the audio is not expected. By default supersdr has a delay of under 0.3s but you can make it even smaller by passing the command line option -b 1
Hope everything will run smoothly, but keep in mind that I never tested the Windows version and it's provided by a friend of mine. I can support only the Linux version and the MacOS should be very similar.
there was a bug in the audiobuffer behavior afflicting especially pulseaudio/ALSA users. I uploaded a new version to git (both dev and main have the new code).
The changelog is this:
There is now a buffer level indication on the bottom bar (for both receivers); the EIBI broadcasting db now shows only the stations actually txing at the moment; the main window can now be dynamically resized; added ADC OVF indicator; several small fixes, among which the ability to create a new kiwi.list database to store kiwi servers directly from the program.
Please let me know especially how the audio buffer behaves! Thanks. @WA2ZKD ;-)
the default buffer size is 10 chunks (the duration in s depends on the kiwi bandwidth 12 or 20 kHz but it's roughly 0.5s I think), this normally works ok for fast remote kiwis, if you have a local kiwi you can go down to 1 for the most realtime experience possible: beware, wired connections are MUCH better for this kind of application, wifi, even if fast, sometimes has a variable ping delay. For slow kiwis I'd go with a buffer of 20:
that Kiwi is marked as "private". I just updated the code to connect to private kiwis. I thought that it was safe not to access them, I don't know what that means...
I'll push the changes in a few minutes to the dev branch, please let me know if all is OK.
Sorry, I was waiting for a commit on master, I overlooked you made your commit to dev. I can confirm it works on Linux on Chrome OS, however with a lot of audio glitches. I suppose the glitches are due to the audio emulation.
The owner of that particular KiwiSDR has the same issue on Debian, I will ask him to test.
Linux on Chromebook (the Crosstini project) is a virtual machine with XWindow and audio streamed to ChromeOS system (which itself is a slimmed up and modded Linux).
Frankly I don't think it is worth our time to dig deeper into the ChromeOS issues. The Crosstini is not that popular.
I really like this, I'm using the Windows version so it would be great to have a latest version Windows build as I'm not techie enough to do that myself. The font at the top in red is quite difficult to read (poor contract and "thin" font). I've got it set for a medium screen size at present but I do have a 4K 32" in screen. As you've said in a previous entry, the font cannot be scaled at the moment. That is fine but could a more "solid/bold" font be used?
CAT control from Icom-725 checked on RaspberryPi3 / debian Linux 10 (buster).
Finally had a chance to try CAT control from a borrowed and dusty Icom 725 rig. So the CAT control works well except when making quick movements with the tuning knob. There seems to be a timing issue between SuperSDR and rigctld with these rapid movements and the latter is "kicked off"
I also checked this with version 3.12 and there this rigctld disconnect happens much sooner. Really great improvements in display readability in version 3.14 !
73 Ben
Edit : For comparison additional info behaviour when using Hamlib Net rigctl with some other applications:
WSJT-X also looses connection with rapid movements (Setting: polling interval 1 sec)
FLDIGI never looses track but needs a short time to catch up with frequency. (Settings : polling interval 100 msec, retries 5, time out 1000 msec)
thanks for the report! It's cool that an old radio like the IC-725 can do CAT.
I think that the problem is on the Hamlib side. I had similar problems when trying to catch the TX/RX switch on my TS-590SG: the rigctld would sometimes disconnect. So I ended up disabling the auto mute feature.
You could insert some delay as you saw in FLDIGI but the normal operation could be much worse.
Thank you for the response and indeed it might very well be a Hamlib Net rigctl issue.
I did get somewhat better frequency following after changing 'settimeout' to 9 sec in utils_supersdr, this of course at the expense of the response time. This old rig has the serial output running at 9600 baud which may also be a factor.
regarding CAT control via Hamlib: I found out that on some computers I have got here, with the last Hamlib version (4.4-1 for Arch/Manjaro), SuperSDR becomes very slow to update the frequency when tuning on the radio. Reverting back to 3.3 fixes the problem. On other computers there is no difference... I don't know why this happens.
Comments
Hi Marco,
That works great :-)
Thanks for the additional information.
Regards,
Martin
Today I fixed a desync problem that arised when the network stutters, leading to a waterfall ahead of the audio. In the worst cases it meant a several seconds delay.
Then I stopped using the default Monospaced font (that depends on what you have installed!) and added the Terminus font that I really like for readability and style. I also reworked a bit the size to be easier on the eyes. Hope it helps!
Other improvements:
This version is only available from the git dev branch, the others will have to wait a bit, as usual...
Hello.
I am trying supersdr on my chromebook / Crosstini Linux. I am getting the following error message on connect:
KiwiSDR Server: 10.0.0.16:8073
Zoom factor: 8
{'status': 'private', 'offline': 'no', 'name': '0-30 MHz SDR | Solnice', 'sdr_hw': 'KiwiSDR v1.506 \u2063 📻 DRM \u2063', 'op_email': 'ok1hra@gmail.com', 'bands': '0-30000000', 'freq_offset': '0.000', 'users': '0', 'users_max': '4', 'avatar_ctime': '1648786922', 'gps': '(0.000000, 0.000000)', 'gps_good': '0', 'fixes': '0', 'fixes_min': '0', 'fixes_hour': '0', 'tdoa_id': '', 'tdoa_ch': '4', 'asl': '400', 'loc': 'Solnice', 'sw_version': 'KiwiSDR_v1.506', 'antenna': 'Multi array', 'snr': '2,2', 'adc_ov': '0', 'uptime': '15946', 'gps_date': '0,0', 'date': 'Sat Apr 2 11:39:24 2022'}
0 4
KiwiSDR offline or under maintenance! Failed to connect!
I have the following questions regarding the networking protocol and the claimed low latency: Does supersdr receive IQ for the whole waterfall and calculate the waterfall + demodulated audio from it, or does it receive processed waterfall data + demodulated audio the same way the Web based front end does? If supersdr receives the same data as the Web based front end, then I wonder why supersdr claims much lower latency than the Web based front end.
73, Vojtech OK1IAK
I have to add a lot of buffering (hence latency) with the KiwiSDR UI due to the large amount of jitter and scheduling delay present when playing audio through all the different browsers/device combinations.
This uncertainty is not present with SuperSDR since no browser is involved. But of course there are trade-offs (software installation being the most significant one I would say).
Although probably caused by the Pulseaudio in my Linux desktop, I have no issue with audio via the Browser and Kiwi web based UI but with SuperSDR I have an underrun problem. I do not have that problem on other boxes. So there is a good example of the Kiwi's buffer helping.
Hi Vojtech,
as John wrote above, I do exactly as the standard web UI, but you can reduce the latency a lot by using the runtime option -b 1 if the kiwi you're connecting to has a fast internet connection or is in your local network. I can use Kiwis on the other side of the world with that setting and I only rarely have problems. The default buffering is 10 or 15, I don't remember.
Regarding your error, I believe that the kiwi to which you were connecting was upgrading the software, or it's set as "private". Usually the status should be "active".
You may download the latest version 3.13 with several updates from the the github page as usual.
73,
marco
Hello Marco.
Is it really a "-b 1" parameter? Looking into the main.c source code, there is no such parameter.
73, Vojtech OK1IAK
Vojtech,
the program is pure Python, where did you find a main.c? :-D
Just run: supersdr.py --help
and you'll see all possible runtime options.
Thanks Jim for the help ;)
Trying out the 3.12 Windows(10) version.... it doesn't seem to find my local kiwi so typing in the ip/port everytime is a hassle. Same with other KIWI's, I was hoping it would store those for quicker access next time - maybe it does but I haven't found the secret yet.
The other comment is the delay in the audio stream is huge. The waterfall seems quick but the audio delay is perhaps 10 seconds or more. The regular KIWI software is much quicker on the same machine. Something else I haven't found the secret to?
Thanks for any insight and for making the program available.
Don
Hi Don,
thanks for the feedback.
If Windows doesn't find your kiwisdr.local just create a batch file using the command line option to directly connect to the server IP. Something like
supersdr.exe -S 192.168.1.82 -P 8073 -w yourpasswordbut you can see all command line options by running
supersdr.exe --helpYou may avoid the -P and -w and it will just use the default 8073 and no password.
Alternatively, create a file with a text editor called
kiwi.listwith these lines:KIWIHOST;KIWIPORT;KIWIPASSWORD;COMMENTS192.168.1.82;8073;;my super kiwi receiverOnce you create the file you can add other KiwiSDRs by pressing q within the program. There you can just connect or save the new server to file and connect. The first line in the file gets ignored, so either you manually create the file or, within the program, save a first fake server (it will be seen as a comment line) and then the server(s) you want.
The delay in the audio is not expected. By default supersdr has a delay of under 0.3s but you can make it even smaller by passing the command line option
-b 1Hope everything will run smoothly, but keep in mind that I never tested the Windows version and it's provided by a friend of mine. I can support only the Linux version and the MacOS should be very similar.
73,
marco
Hi,
there was a bug in the audiobuffer behavior afflicting especially pulseaudio/ALSA users. I uploaded a new version to git (both dev and main have the new code).
The changelog is this:
There is now a buffer level indication on the bottom bar (for both receivers); the EIBI broadcasting db now shows only the stations actually txing at the moment; the main window can now be dynamically resized; added ADC OVF indicator; several small fixes, among which the ability to create a new kiwi.list database to store kiwi servers directly from the program.
Please let me know especially how the audio buffer behaves! Thanks. @WA2ZKD ;-)
73,
marco
PS to the previous message:
the default buffer size is 10 chunks (the duration in s depends on the kiwi bandwidth 12 or 20 kHz but it's roughly 0.5s I think), this normally works ok for fast remote kiwis, if you have a local kiwi you can go down to 1 for the most realtime experience possible: beware, wired connections are MUCH better for this kind of application, wifi, even if fast, sometimes has a variable ping delay. For slow kiwis I'd go with a buffer of 20:
./supersdr.py -b 20On windows:
supersdr.exe -b 20Ciao!
Hello Marco.
I get the following error message even with the latest source code on Linux / ChromeOS.
Is there any logging I should enable to get a more informative log?
Thanks and 73, Vojtech OK1IAK
bubnikv@penguin:~/supersdr$ ./supersdr.py
pygame 2.1.2 (SDL 2.0.9, Python 3.7.3)
Hello from the pygame community. https://www.pygame.org/contribute.html
no logfile found!
No kiwi list file found!
RTX rigctld server: localhost:4532
CAT radio not detected!
kiwisdr.local 8073 8 14200
KiwiSDR Server: kiwisdr.local:8073
Zoom factor: 8
[]
KiwiSDR Server: hra.remoteqth.com:8073
Zoom factor: 8
{'status': 'private', 'offline': 'no', 'name': 'OK1HRA, 0-30 MHz | Deep forest, JO60WA, Krivoklat, Czechia, EU', 'sdr_hw': 'KiwiSDR v1.514 \u2063 📡 GPS \u2063 📻 DRM \u2063', 'op_email': 'ok1hra@gmail.com', 'bands': '0-30000000', 'freq_offset': '0.000', 'users': '7', 'users_max': '8', 'avatar_ctime': '1650936232', 'gps': '(50.033355, 13.835709)', 'gps_good': '3', 'fixes': '59879', 'fixes_min': '30', 'fixes_hour': '769', 'tdoa_id': '', 'tdoa_ch': '-1', 'asl': '450', 'loc': 'Deep forest, JO60WA, Krivoklat, Czechia, EU', 'sw_version': 'KiwiSDR_v1.514', 'antenna': 'ball of wire', 'snr': '23,23', 'adc_ov': '130', 'uptime': '365308', 'gps_date': '0,0', 'date': 'Sat Apr 30 06:52:40 2022'}
7 8
KiwiSDR offline or under maintenance! Failed to connect!
[]
Traceback (most recent call last):
File "./supersdr.py", line 107, in <module>
kiwi_wf = kiwi_waterfall(kiwi_host, kiwi_port, kiwi_password, zoom, freq, eibi, disp)
File "/home/bubnikv/supersdr/utils_supersdr.py", line 654, in __init__
raise Exception()
Exception
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "./supersdr.py", line 113, in <module>
kiwilist.main_dialog.update()
File "/usr/lib/python3.7/tkinter/__init__.py", line 1177, in update
self.tk.call('update')
_tkinter.TclError: can't invoke "update" command: application has been destroyed
OK Vojtech,
that Kiwi is marked as "private". I just updated the code to connect to private kiwis. I thought that it was safe not to access them, I don't know what that means...
I'll push the changes in a few minutes to the dev branch, please let me know if all is OK.
marco
Hi Marco.
Thanks, I am looking forward to test it.
Vojtech
Hi Marco.
Sorry, I was waiting for a commit on master, I overlooked you made your commit to dev. I can confirm it works on Linux on Chrome OS, however with a lot of audio glitches. I suppose the glitches are due to the audio emulation.
The owner of that particular KiwiSDR has the same issue on Debian, I will ask him to test.
Thanks and 73, Vojtech OK1IAK
OK Vojtech,
thanks for the report. Unfortunately I've never seen a Chromebook live.
I have no idea what differences there are between a normal Linux distro and that as regards the audio subsystem.
If there are glitches what happens when you increase the buffer value with -b 30 for example?
marco
I tried to increase buffers, it did not help.
Linux on Chromebook (the Crosstini project) is a virtual machine with XWindow and audio streamed to ChromeOS system (which itself is a slimmed up and modded Linux).
Frankly I don't think it is worth our time to dig deeper into the ChromeOS issues. The Crosstini is not that popular.
Vojtech
I really like this, I'm using the Windows version so it would be great to have a latest version Windows build as I'm not techie enough to do that myself. The font at the top in red is quite difficult to read (poor contract and "thin" font). I've got it set for a medium screen size at present but I do have a 4K 32" in screen. As you've said in a previous entry, the font cannot be scaled at the moment. That is fine but could a more "solid/bold" font be used?
Hi @Gibsonmb,
I'll have to force my Windows friend to work a bit more :-)
I'll try to do something about the fonts, maybe through a command line option.
marco
Would this bold font be OK? I cannot change font size (for now) because some things are not parametric. On my display legibility seems quite good now.
Hi Marco,
CAT control from Icom-725 checked on RaspberryPi3 / debian Linux 10 (buster).
Finally had a chance to try CAT control from a borrowed and dusty Icom 725 rig. So the CAT control works well except when making quick movements with the tuning knob. There seems to be a timing issue between SuperSDR and rigctld with these rapid movements and the latter is "kicked off"
I also checked this with version 3.12 and there this rigctld disconnect happens much sooner. Really great improvements in display readability in version 3.14 !
73 Ben
Edit : For comparison additional info behaviour when using Hamlib Net rigctl with some other applications:
WSJT-X also looses connection with rapid movements (Setting: polling interval 1 sec)
FLDIGI never looses track but needs a short time to catch up with frequency. (Settings : polling interval 100 msec, retries 5, time out 1000 msec)
Hi Ben,
thanks for the report! It's cool that an old radio like the IC-725 can do CAT.
I think that the problem is on the Hamlib side. I had similar problems when trying to catch the TX/RX switch on my TS-590SG: the rigctld would sometimes disconnect. So I ended up disabling the auto mute feature.
You could insert some delay as you saw in FLDIGI but the normal operation could be much worse.
SO for the moment, avoid fast QSYs :-D
73,
marco IS0KYB
Hi Marco,
Thank you for the response and indeed it might very well be a Hamlib Net rigctl issue.
I did get somewhat better frequency following after changing 'settimeout' to 9 sec in utils_supersdr, this of course at the expense of the response time. This old rig has the serial output running at 9600 baud which may also be a factor.
73 Ben
Ah, 9600 baud!
That's likely why I've never seen any problem working at 115kbps...
I could put in a new command line param to change the timeout for old and slow rigs.
Hi All,
regarding CAT control via Hamlib: I found out that on some computers I have got here, with the last Hamlib version (4.4-1 for Arch/Manjaro), SuperSDR becomes very slow to update the frequency when tuning on the radio. Reverting back to 3.3 fixes the problem. On other computers there is no difference... I don't know why this happens.
marco
Hi Marco,
Is there a fresh Windows executable of SuperSDR. I have now this:
73´s
Pekka
Hi Pekka,
no there is no updated Windows executable.
Don't expect anything for at least one month.
marco
are the exe files created with pyinstaller?