v1.281: signal generator extension, audio FFT fixes
From the CHANGE_LOG file:
v1.281 April 12, 2019
Add URL parameter "peak" to set spectrum peak hold mode (overrides last value saved in cookie)
e.g. "&peak", or redundantly "&peak=1", but more usefully "&peak=0"
Audio FFT:
Allow URL parameter "no_wf" to be used in 4 and 3-channel modes, not just 8-channel mode.
This is useful e.g. if you want to use the audio FFT to study the frequency response of
the new de-emphasis filter in 20 kHz mode (3-channel mode) where you would otherwise
never be given the audio FFT because there is no shortage of waterfall channels.
Added missing window function to FFT.
Fixed scale/waterfall click frequency in non-IQ modes.
Added signal generator extension. When enabled replaces ADC input to audio/waterfall DDCs
with a tunable RF signal source using the same FPGA DDS IP block used by the DDC mixers.
WARNING: Be careful about drawing conclusions re Kiwi performance and possible bugs
when using the sig gen. It reveals spurious responses in the waterfall/spectrum to a greater
degree than if you just tune around with an antenna connected. But without detailed
experimentation it can be difficult to know where the limitations are. Remember that the
Kiwi is a carefully balanced compromise to get 4-channel mode to work (i.e. fit in the FPGA
and have enough Beagle CPU cycles). So the DDSs, mixers, DDCs and FFTs are not perfect.
Speaking of compromise, when considering FFTs it's important to understand this:
https://en.wikipedia.org/wiki/Spectral_leakage
Comments
This is an interesting addition.
Is there any way the signal generator output could be routed to the outside world, for example on one of the GPIO pins, or by means of a hardware hack ?
Regards,
Martin - G8JNJ
I've had this sig gen capability for years but have resisted releasing it (until now) because I just knew it was going to cause trouble for me. But it has some utility now sweeping filters and whatnot (edit: I meant internal to the Kiwi).
But it's not a terribly clean signal. The SFDR is only about 90 dB. This is because this is the greatest SFDR that can be wrung out of the Xilinx DDS IP block so that it uses only a single "BRAM" (FPGA memory block). BRAMs are the FPGA resource that is in shortest supply. With the addition of the sig gen 100% of the BRAMs are now in use. Every single one (for the rx4/wf4 configuration).
This sort of functionality is almost certainly beyond the charter of an SDR receiver but it is nevertheless a terribly useful piece of test equipment and one that is probably quite under-appreciated. It could go well past scalar, magnitude only measurements of filters (or whatnot).
The spectral purity of a source like that would certainly be an issue and I'm not sure how one would easily implement a tracking filter or other sine-wave approximation from a square wave but the possibilities are intriguing.
Maybe you've just let the cat out of the bag John
OK that sounds EXTREMELY promising.
My thoughts were that it could be used for a few purposes.
1. Used as a frequency reference to lock external transvertors / convertors to the KiWi. Especially if folks are now getting interested in possibly using the KiWi for VHF/UHF & Microwave bands. For those of us lucky enough to be within the footprint of the new Es'Hail QO-100 geostationary amateur radio satellite transponder, this sort of technique is being used to lock the 25 or 27MHz reference in place of the domestic LNB internal crystal when down converting from 10GHz.
2. Used as a handy signal generator to test the gain / frequency response of items placed ahead of the KiWi, which would allow alignment of items such as BC notch filters and slope equalisers.
3. Testing the gain / frequency response of antennas used with the Kiwi. If the output signal is a square wave. it may be possible to set say a frequency of 1MHz (or 100KHz) and use the output as a comb generator instead of having to sweep it.
4. If the output level into the ADC is known, then if the signal could be applied to an external device,such as a filter or pre-amp, and a calibration correction could be derived and internally generated from the stored results. This would allow automatic S-Meter calibration to be achieved.
5. Could the generated signal be time stamped with internally GPS derived pulses or 'clicks' so that it could be used to test / calibrate the TDoA when required.
Misc musings......
In order to keep P8 clear for possible expansion of GPIO switching, would it be feasible to use any of the 'spare' pins on P9.
P9 - 11 GPIO mode 7 0_30
P9 - 23 GPIO mode 7 1_17
P9 - 26 GPIO mode 7 0_14 (not sure if this one could be used)
Unlike most other extensions which don't cause problems for multiple users, when the signal generator is in use it prevents all other users from receiving any off-air signals.
Maybe the Signal Generator controls should be in the admin menu rather than available to users as an extension. This would also allow it to be permanently enabled if it was required to lock a convertor.
For items 2-4 it would be nice to have two 'peak hold traces' - Yeh, nah :-) so that you could compare 'before' and 'after' results of any changes.
Now taking cover......
Regards,
Martin - G8JNJ