@LIN_in that is an interesting suggestion to add the callsign. I had it early on my todolist, but somehow it got forgotten. Will implement it in the next version. You will be able to enter your callsign in the settings. if you leave it empty the existing fingerprint callsign will be generated (as is the case now).
I agree with @ZL2P that static buttons, while convenient, take away valuable screen real estate that is better spent on dynamic data such as spectrum and WF. I'd like to see grid lines for both axes, 10 dB/div for Y axis in spectrum and 5-10 in X axis at the zoom level.
I think the use of COL for spectrum is incorrect. IMO, COL can best be selected in WF by user to provide preferred contrast and characteristics, especially at low levels near the noise, but the corresponding amplitude information in spectrum mode should not be color as it presently is. Rather it should be vertical position - a spectrogram as on a spectrum analyzer. There is far more information conveyed with this sort of representation than with color.
WF is useful for gathering a temporal record, where that is important, but spectrum is a frequency record. Absolute and relative signal levels, noise and signal signatures are far better communicated in this mode with a Y axis that is amplitude. The WF color map can be used in spectrum as well, though even monochrome on a spectrum display can convey the same wealth of information.
I'd rather see the button space reduced, perhaps through drop-down menus, and the reclaimed display space used for spectrum and WF.
First, a question: do you use a spectrum display on a radio in the same way as on a measuring device? I’m not a specialist in this matter, but I would say that a spectrum display on a radio is used primarily to assist with tuning rather than for precise measurements. It’s more of a visual tuning aid than an exact measuring instrument, I suppose?
Secondly, you are right that the band buttons would ideally be replaced with a spectrum display. I’ll think about that, as mentioned earlier, but I’m concerned about hitting the limits of the processing power of an average smartphone (flagship phones won’t have a problem). I already had to create 19 versions of my audio processor before I managed to avoid hiccups with the audio packets and waterfall packets being handled in real time. I fear that adding an additional spectrum display in parallel might cause hiccups again (I’ll try a test version with both spectrum and waterfall running simultaneously to get a definitive answer). On a typical streaming app (video and/or audio), you can add buffering to prevent hiccups, but I can’t add too much buffering here, since the goal is to provide a real-time tuning experience with the lowest possible latency between changing frequency and hearing the audio packets.
You ask a very pertinent question. I think the users and uses of a spectrum or WF display are varied so there isn't a single best answer. My own uses usually tend toward using it is a measuring device. But that can be in the process of improving ham station performance and also while operating the station to understand conditions and adjustments while making a contact. So my opinion is that both use models are important, though perhaps my main one is in the minority.
I understand the limits the phone environment puts on you and of course you're the best one to make trade-offs that stress these. However, I think what you already have running is very close to enough. Whether you run both WF and spectrum at the same time to me isn't critical. I'd be happy to select between the two based on my particular use case. The few simple changes to display of the data you are already presenting could, I think, make what you have even better for both measurers and operators alike. I don't think there's much additional cpu demand from the few changes I'd like to see, they are mainly static display characteristics of what you already have. I think they would make better use of the valuable display real estate available.
In the end only you know who and what your target audience is and what you'd like to do. I think the rest of us can only provide input suggestions, bug reports and thanks for your significant contribution to the utility of our Kiwis.
I'm finding the app to be very useful, thanks for doing this. I have the key you sent, PayPal didn't forward me to any page but maybe that was adblock blocking something.
My initial request is around customization of the band buttons and the server window.
I'd like to type in my own url - not all my devices are public and I'd like to select that one by typing directly into the window.
I'd also like to have the ability to edit the 24 band buttons, to have them go to frequencies of my choosing and have the labels reflect that. That would make it very fast and flexible, reminds me of the Sony ICF2010 32 key memory arrangement which is still the best ever, in my opionion.
@ve6jy thank you for your feedback. I also like those old receivers like the Sony ICF2010 and others.
It is already possible to enter your own kiwi server url: click on the server list and enter your url in the field and click Select.
I will take note of your other suggestion about the custom band buttons. Have to think about it how I can integrate it neatly.
FYI: I am working on version 2 which I will release shortly (I am testing right now). This is a major change in the interface: I listened to users feedback and you will have both a waterfall and spectrum display (with gridlines and dBm meter) on the screen, and the band buttons will be dropdown, step mode, separate station seek button, ...
• New interface with both Waterfall and FFT Spectrum on the display
• FFT spectrum has a scaling grid and a dBm measurement
• Selection between Color and B/W FFT graph
• Band buttons are available via a dropdown selector
• Dedicated buttons for Station SEEK and Station STEP mode
• Bug fixes + ui-improvements
I have listened to the users feedback and reused the space occupied by the band buttons to show both Waterfall and FFT Spectrum on the screen. The FFT and Waterfall can be switched off to reduce bandwidth and processing power.
The Band buttons are available via a drop-down selector.
The automatic station detection using the AOKI Shortwave Frequency Database now has a dedicated SEEK button.
There is a new STEP mode button, to cycle through the preset memories using < and >.
The first one you mention is not a true Kiwi, but a clone that runs very old software (v1.690). So it probably has API compatibility issues. I do not provide support for clones. And, sadly, they don't seem to either (the clone forums are full of people who can't get support).
The VHF/UHF ones require detecting the offset via API and adjusting the frequency scale. But the API will still be baseband referenced, i.e. 0 - 30/32 MHz. It's a bit complicated. I will have to go through the code and identify all the places you need to consider applying the offset.
All of these air band signals will be AM mode. The Switzerland one worked for me, but has a huge number of spurious signals. Look for intermittent signals representing the short AM transmissions. The Russian one is another clone running v1.690 so probably won't work for that reason. You can identify these by connecting using the Kiwi web interface and checking the v1.xxx version number of the user control panel "Stat" tab.
I already got information from another contact that they (probably) are clones. So I don't have to bother debugging them further.
About the VHF/UHF servers: you do not need to look in the code, I already figured it out and rewrote my code to work with the offset. It is indeed quite complicated, because as you said, internally it is handled without the offset. But I am almost ready with my rewrite so I will support those VHF/UHF servers shortly. Need some testing, because that offset induced quite some code rewrites. I need to check if my previous code for 99% of the servers keeps working correctly before I release that version.
I don't think he has very good front end filtering on that downconverter. That 120 MHz signal is almost certainly an FM broadcast band image. It is 100 kHz wide and the audio clears up slightly in AM mode when you tune off to the side (AM slope demodulation). So it's standard 100 kHz (+/- 50 kHz) wide band FM (WBFM) which the Kiwi cannot currently decode because it doesn't implement a 100 kHz wide audio channel (20.25 kHz max in 3-channel mode, 12 kHz in all the other modes).
Also note the AM air band transmissions on 115.85 MHz buried under that wide digital signal. Is that some sort of digital TV signal? Seems like another image that isn't actually in the air band.
First of all I did not write the squelch code, so I can't say exactly how it works. But it was originally designed for the NBFM modes. So using it outside that context is perhaps a bit problematic. I think it tries to compare energy at and above typical voice frequencies and use that as a basis for squelching. So it probably isn't going to work at all on AM BCB signals where there are very few periods of silence.
It works well however on things like the digital bursts in the UK on e.g. 4037.5 kHz. In either USB or AM modes.
I should also mention, re your earlier query about VHF/UHF Kiwi, that a reason to detect and respond to dynamic changes in the offset is because it is possible for this to be set in the antenna switch configuration. So that a user connection could select an antenna that also switches a downconverter in/out-of-line. On the Kiwi UI this causes a page reload to correct the frequency scale and all the other places the new offset needs to be taken into account.
But in practice I don't think many Kiwi are setup this way. VHF/UHF operation seems to be a static setup rather than associated with an antenna configuration.
Could you, please, try your app. with stations in 3 channels/20 kHz audio sampling rate mode ? I think there is a problem. See on AM broadcast stations, -it is- a sampling rate problem. Here is the list :
• Support for UHF-, VHF- and all servers starting above 32 MHz + extra frequency digit added: 0-999999.99 kHz
• New "Selective Preset Scan/Step" mode (always active): Scan/Step only search results of memory presets
• New "Scan Stop on Squelch Treshold" mode: Stop scanning when Squelch treshold exceeded, restart after 4 seconds of mute
• New "FFT Auto Range Send Treshold (dBm)" setting: sets the delta change treshold before sending new mindBm or maxdBm values to the server
• New "Keep Audio Settings" mode: save/restore audio settings at stop/start of radio (NR, COMP, ADPCM, Volume, Squelch)
• New version check in settings
• Bug fixes + ui-improvements
The new "Selective Preset Scan/Step" mode allows to scan/step only search results of memory presets (filtered by search).
This allows interesting new features, depending on how you name your presets, like:
• scanning/stepping only certain countries if you name your presets like "presetname (countrycode)" and search on (countrycode)
• scanning/stepping only on stations that have certain strings in their name: f.i. "BBC".
• scanning/stepping only on certain channels of a band and a certain mode: f.i. if you named your 40m band channels "40m Chan #".
If you want to search all stations (in the current mode), simply clear the presets search field or reset the search results to all.
The new "Scan Stop on Squelch Treshold" mode allows to simulate a scanner function.
It has some complex features but simply said it pauses scanning when squelch treshold is reached as long as there is audio. When audio mutes for 4 seconds, scanning is resumed.
Typical example could be: select Airband server. Create a set of frequency presets and name them consistenly like AIR C1, AIR C2, etc.
Make sure Scan Stop on Squelch Treshold is active, set Scan Interval to 1000 ms (1 second) and set Squelch level to desired value.
Search for presets "AIR" and start scanning. Scanning will switch the AIR channels every 1 second until audio. Scanning resumes after 4 seconds of silence otherwise scanning stays paused for smaller mutes.
The new "FFT Auto Range Send Treshold (dBm)" setting sets the delta change treshold before sending new mindBm or maxdBm values to the server. Helpfull to reduce server requests when your station signal fluctuates alot (like f.i. on VHF/UHF airband server), you could set it to 10 or 20 dBm, so it only sends a new range to the server every second when either mindBm or maxdBm deltas exceed that treshold (default 5 dBm).
Comments
@LIN_in that is an interesting suggestion to add the callsign. I had it early on my todolist, but somehow it got forgotten. Will implement it in the next version. You will be able to enter your callsign in the settings. if you leave it empty the existing fingerprint callsign will be generated (as is the case now).
I agree with @ZL2P that static buttons, while convenient, take away valuable screen real estate that is better spent on dynamic data such as spectrum and WF. I'd like to see grid lines for both axes, 10 dB/div for Y axis in spectrum and 5-10 in X axis at the zoom level.
I think the use of COL for spectrum is incorrect. IMO, COL can best be selected in WF by user to provide preferred contrast and characteristics, especially at low levels near the noise, but the corresponding amplitude information in spectrum mode should not be color as it presently is. Rather it should be vertical position - a spectrogram as on a spectrum analyzer. There is far more information conveyed with this sort of representation than with color.
WF is useful for gathering a temporal record, where that is important, but spectrum is a frequency record. Absolute and relative signal levels, noise and signal signatures are far better communicated in this mode with a Y axis that is amplitude. The WF color map can be used in spectrum as well, though even monochrome on a spectrum display can convey the same wealth of information.
I'd rather see the button space reduced, perhaps through drop-down menus, and the reclaimed display space used for spectrum and WF.
Thanks for making this nice app.
@n6gn Thank you for your valuable feedback!
First, a question: do you use a spectrum display on a radio in the same way as on a measuring device? I’m not a specialist in this matter, but I would say that a spectrum display on a radio is used primarily to assist with tuning rather than for precise measurements. It’s more of a visual tuning aid than an exact measuring instrument, I suppose?
Secondly, you are right that the band buttons would ideally be replaced with a spectrum display. I’ll think about that, as mentioned earlier, but I’m concerned about hitting the limits of the processing power of an average smartphone (flagship phones won’t have a problem). I already had to create 19 versions of my audio processor before I managed to avoid hiccups with the audio packets and waterfall packets being handled in real time. I fear that adding an additional spectrum display in parallel might cause hiccups again (I’ll try a test version with both spectrum and waterfall running simultaneously to get a definitive answer). On a typical streaming app (video and/or audio), you can add buffering to prevent hiccups, but I can’t add too much buffering here, since the goal is to provide a real-time tuning experience with the lowest possible latency between changing frequency and hearing the audio packets.
You ask a very pertinent question. I think the users and uses of a spectrum or WF display are varied so there isn't a single best answer. My own uses usually tend toward using it is a measuring device. But that can be in the process of improving ham station performance and also while operating the station to understand conditions and adjustments while making a contact. So my opinion is that both use models are important, though perhaps my main one is in the minority.
I understand the limits the phone environment puts on you and of course you're the best one to make trade-offs that stress these. However, I think what you already have running is very close to enough. Whether you run both WF and spectrum at the same time to me isn't critical. I'd be happy to select between the two based on my particular use case. The few simple changes to display of the data you are already presenting could, I think, make what you have even better for both measurers and operators alike. I don't think there's much additional cpu demand from the few changes I'd like to see, they are mainly static display characteristics of what you already have. I think they would make better use of the valuable display real estate available.
In the end only you know who and what your target audience is and what you'd like to do. I think the rest of us can only provide input suggestions, bug reports and thanks for your significant contribution to the utility of our Kiwis.
Best,
Glenn n6gn
@LIN_in it is now possible in version QiwiQ-1.45.04 to enter your own Name/CallSign instead of the automatically assigned fingerprint (via settings).
I'm finding the app to be very useful, thanks for doing this. I have the key you sent, PayPal didn't forward me to any page but maybe that was adblock blocking something.
My initial request is around customization of the band buttons and the server window.
I'd like to type in my own url - not all my devices are public and I'd like to select that one by typing directly into the window.
I'd also like to have the ability to edit the 24 band buttons, to have them go to frequencies of my choosing and have the labels reflect that. That would make it very fast and flexible, reminds me of the Sony ICF2010 32 key memory arrangement which is still the best ever, in my opionion.
Thanks and 73
Don VE6JY
@ve6jy thank you for your feedback. I also like those old receivers like the Sony ICF2010 and others.
It is already possible to enter your own kiwi server url: click on the server list and enter your url in the field and click Select.
I will take note of your other suggestion about the custom band buttons. Have to think about it how I can integrate it neatly.
FYI: I am working on version 2 which I will release shortly (I am testing right now). This is a major change in the interface: I listened to users feedback and you will have both a waterfall and spectrum display (with gridlines and dBm meter) on the screen, and the band buttons will be dropdown, step mode, separate station seek button, ...
Check here soon. ;-)
New version of QiwiQ released: 2.02
• New interface with both Waterfall and FFT Spectrum on the display
• FFT spectrum has a scaling grid and a dBm measurement
• Selection between Color and B/W FFT graph
• Band buttons are available via a dropdown selector
• Dedicated buttons for Station SEEK and Station STEP mode
• Bug fixes + ui-improvements
I have listened to the users feedback and reused the space occupied by the band buttons to show both Waterfall and FFT Spectrum on the screen. The FFT and Waterfall can be switched off to reduce bandwidth and processing power.
The Band buttons are available via a drop-down selector.
The automatic station detection using the AOKI Shortwave Frequency Database now has a dedicated SEEK button.
There is a new STEP mode button, to cycle through the preset memories using < and >.
Download at: https://bit.ly/3I49LfD
Feedback/bugs welcome!
Nice job is undoubtedly worth of a cup of coffee ☕️
New version of QiwiQ released: 2.05.20
• New FFT Auto maxdBm adjustment: auto-adjusts the maxdBm value to the maximum signals received (always active)
• New FFT Auto Noise-Floor mode: auto-adjusts the noise-floor value (switch on/off and set offset in settings)
• BASE button replaces SCALE button: drag up/down to shift the base noise floor (when FFT Auto Noise-Floor is off)
• FFT Auto Noise-Floor mode can be temporarily disabled from AUTO to BASE mode (manual adjust)
• Both AUTO and BASE buttons can be dragged to change the noise-floor offset
• mindBm and maxdBm labels (bottom/top values) added to the FFT display
• FFT Grid-lines at 10dBm multiples
• Signal-meter bug fix and + sign for values over S9 (Sx for x <= 9, S+x for x>9)
• Frequency clamping removed for servers > 30 MHz (Fix)
• SEEK now rounds the current frequency to the nearest kHz to make seeking stations in the database easier
• Kiwiservers database auto-updated every 20 minutes in github
• Stations database auto-updated dayly in github
• Faster startup using custom kiwiservers- and stationdatabase in github
• Bug fixes + ui-improvements
Download at: https://bit.ly/3I49LfD
Feedback/bugs welcome!
Thank you! The app looks and works better with each release. I am looking forward to what the future brings!
@jks and others:
I noticed that QiwiQ cannot connect to certain servers, like:
http://wessex.hopto.org:8075/?f=10Mamnz10
Strangely I can open the socket, but no data received.
What could be the reason why they refuse to connect? Timing problem?
Another question: there seem to be at least 2 kiwi-servers in the region of 110-148 MHz.
How do I have to handle them? Should I shift my frequency range starting at 110/118/...?
Also audio is distorted using the standard available modulation modes.
What modulation is used? Does Kiwi support demodulation modes for this? Which?
110-142MHZ AIRBAND KIWISDR | SWITZERLAND HASENBERG04 AG 700M / ANTENNA: VHF OMNI
http://hasenberg04.proxy.kiwisdr.com:8073/?f=10Mamnz10
118-148 MHZ AIRBAND+SAT+2M BAND | KRASNOARMEYSK, RUSSIA
http://std.swl.su:8073/?f=10Mamnz10
The first one you mention is not a true Kiwi, but a clone that runs very old software (v1.690). So it probably has API compatibility issues. I do not provide support for clones. And, sadly, they don't seem to either (the clone forums are full of people who can't get support).
The VHF/UHF ones require detecting the offset via API and adjusting the frequency scale. But the API will still be baseband referenced, i.e. 0 - 30/32 MHz. It's a bit complicated. I will have to go through the code and identify all the places you need to consider applying the offset.
All of these air band signals will be AM mode. The Switzerland one worked for me, but has a huge number of spurious signals. Look for intermittent signals representing the short AM transmissions. The Russian one is another clone running v1.690 so probably won't work for that reason. You can identify these by connecting using the Kiwi web interface and checking the v1.xxx version number of the user control panel "Stat" tab.
Thank you @jks for your useful information.
I already got information from another contact that they (probably) are clones. So I don't have to bother debugging them further.
About the VHF/UHF servers: you do not need to look in the code, I already figured it out and rewrote my code to work with the offset. It is indeed quite complicated, because as you said, internally it is handled without the offset. But I am almost ready with my rewrite so I will support those VHF/UHF servers shortly. Need some testing, because that offset induced quite some code rewrites. I need to check if my previous code for 99% of the servers keeps working correctly before I release that version.
I try to figure out the modulation of certain frequencies on this VHF/UHF server to try to support it in QiwiQ:
http://hasenberg04.proxy.kiwisdr.com:8073/?f=10Mamnz10
If you tune f.i. to 120000 kHz you can hear a distorted music channel. There are more nearby.
What modulation is used? Or are these Receiver Harmonics or Image Frequencies of lower FM frequencies from 88–108 MHz range?
@jks : does Kiwi support FM modulation (not NBFM or NNFM)?
I don't think he has very good front end filtering on that downconverter. That 120 MHz signal is almost certainly an FM broadcast band image. It is 100 kHz wide and the audio clears up slightly in AM mode when you tune off to the side (AM slope demodulation). So it's standard 100 kHz (+/- 50 kHz) wide band FM (WBFM) which the Kiwi cannot currently decode because it doesn't implement a 100 kHz wide audio channel (20.25 kHz max in 3-channel mode, 12 kHz in all the other modes).
Also note the AM air band transmissions on 115.85 MHz buried under that wide digital signal. Is that some sort of digital TV signal? Seems like another image that isn't actually in the air band.
Also note the AM air band transmissions on 115.85 MHz buried under that wide digital signal. Is that some sort of digital TV signal?
Those appear to be DAB+ channels, which are regularly between 175 and 230 MHz.
1536 OFDM carriers with 1 kHz spacing for each channel.
Ah, of course, DAB+ in Europe. Thank you for that.
@jks I noticed a strange behavior of SQUELCH (could be my ignorance).
You can simulate it as follows (also in Kiwi web interface):
select server f.i. http://g8ure.ddns.net:8073/?f=10Mamnz10
select a strong signal: f.i. BBC at 693 kHz.
change the SQUELCH slider and I noticed that already at 1 or 2 dB the squelch starts muting.
Should it not be at a very high dB level for such a strong signal?
Update: I noticed that the behavior is not always the same. I can't find any logic in when it happens and when it doesn't, but it happens a lot.
Update2: I also notice that hysteresis delta between on and off can be quite high
First of all I did not write the squelch code, so I can't say exactly how it works. But it was originally designed for the NBFM modes. So using it outside that context is perhaps a bit problematic. I think it tries to compare energy at and above typical voice frequencies and use that as a basis for squelching. So it probably isn't going to work at all on AM BCB signals where there are very few periods of silence.
It works well however on things like the digital bursts in the UK on e.g. 4037.5 kHz. In either USB or AM modes.
I should also mention, re your earlier query about VHF/UHF Kiwi, that a reason to detect and respond to dynamic changes in the offset is because it is possible for this to be set in the antenna switch configuration. So that a user connection could select an antenna that also switches a downconverter in/out-of-line. On the Kiwi UI this causes a page reload to correct the frequency scale and all the other places the new offset needs to be taken into account.
But in practice I don't think many Kiwi are setup this way. VHF/UHF operation seems to be a static setup rather than associated with an antenna configuration.
Hi @XPloRR Johan, all,
Could you, please, try your app. with stations in 3 channels/20 kHz audio sampling rate mode ? I think there is a problem. See on AM broadcast stations, -it is- a sampling rate problem. Here is the list :
Cheers, T
New version of QiwiQ released: 2.05.36
• Support for UHF-, VHF- and all servers starting above 32 MHz + extra frequency digit added: 0-999999.99 kHz
• New "Selective Preset Scan/Step" mode (always active): Scan/Step only search results of memory presets
• New "Scan Stop on Squelch Treshold" mode: Stop scanning when Squelch treshold exceeded, restart after 4 seconds of mute
• New "FFT Auto Range Send Treshold (dBm)" setting: sets the delta change treshold before sending new mindBm or maxdBm values to the server
• New "Keep Audio Settings" mode: save/restore audio settings at stop/start of radio (NR, COMP, ADPCM, Volume, Squelch)
• New version check in settings
• Bug fixes + ui-improvements
The new "Selective Preset Scan/Step" mode allows to scan/step only search results of memory presets (filtered by search).
This allows interesting new features, depending on how you name your presets, like:
• scanning/stepping only certain countries if you name your presets like "presetname (countrycode)" and search on (countrycode)
• scanning/stepping only on stations that have certain strings in their name: f.i. "BBC".
• scanning/stepping only on certain channels of a band and a certain mode: f.i. if you named your 40m band channels "40m Chan #".
If you want to search all stations (in the current mode), simply clear the presets search field or reset the search results to all.
The new "Scan Stop on Squelch Treshold" mode allows to simulate a scanner function.
It has some complex features but simply said it pauses scanning when squelch treshold is reached as long as there is audio. When audio mutes for 4 seconds, scanning is resumed.
Typical example could be: select Airband server. Create a set of frequency presets and name them consistenly like AIR C1, AIR C2, etc.
Make sure Scan Stop on Squelch Treshold is active, set Scan Interval to 1000 ms (1 second) and set Squelch level to desired value.
Search for presets "AIR" and start scanning. Scanning will switch the AIR channels every 1 second until audio. Scanning resumes after 4 seconds of silence otherwise scanning stays paused for smaller mutes.
The new "FFT Auto Range Send Treshold (dBm)" setting sets the delta change treshold before sending new mindBm or maxdBm values to the server. Helpfull to reduce server requests when your station signal fluctuates alot (like f.i. on VHF/UHF airband server), you could set it to 10 or 20 dBm, so it only sends a new range to the server every second when either mindBm or maxdBm deltas exceed that treshold (default 5 dBm).
Download at: https://bit.ly/3I49LfD
Feedback/bugs welcome!
New version of QiwiQ released: 2.05.44
• Private servers can now be added/deleted as favorites ("Select" button replaced by "Add" button)
• Fix for large "text size" setting in Android
• Fix for big screens
• More robust switching of servers: new server is connected after all sockets and asynchronous functions are closed from previous server
• Bug fixes + ui-improvements
Download at: https://bit.ly/3I49LfD
Feedback/bugs welcome!