The forum is read-only currently.
- Last Active
Not sure if I got all the parameters in but
seems to let one examine the phase of the Kiwi w/ Bodnar against US NIST.
Yes, there's a chance. On my list of interesting projects is a fast-switching block converter. Essentially this would be a transverter (up/down converter) to an IF above the highest frequency of interest, perhaps 3+ GHz. This uses an LO synthesizer of reasonable performance, (e.g. Harris chip set) speed, phase noise etc paired with isolation stages to drive two mixers with BPF filtering. Picture a, say, 3.0 GHz transceiver that converts 10-32 MHz from a Kiwi or other SDR up/down.
That 3.0 GHz IF is then used with another pair of mixers and the same chipset as the fixed LO synthesizer but this time that LO is stepped in [20 MHz] steps from [3.5 - 6.5 GHz] . This is paired with another similar mixer and converts the original 3.5 GHz IF back *down* to 0-3 GHz. Because LOs are identical and use the same reference, phase noise contributions largely cancel and the result is an all-band receiver using the Kiwi as the last 'IF'/detector/demodulator moving anything the base HF KiwiSDR can do at HF to 0-3 GHz. With stitching it becomes a wide band spectrum analyzer as well.
Synthesizers that can do this are pretty inexpensive as are mixers and gain/isolation stages. Other than BPF & LPF filtering, done between planes in the PC board there isn't much to it. Since all LOs can have high PLL bandwidth, close in spurs and phase noise can be that of the base clock which is perhaps coherent with and also providing the 66.660 MHz Kiwi external clock.
A nice side effect of all this is that it can transmit at low power, as well as receive. Low noise pre-amplification and PA stages can be added as desired (or not).
I think it would make a nice open source hardware/software addition to the KiwiSDR and even Apache/Red Pitaya ... style SDR transceivers. With only 20 kHz of information bandwidth, the Kiwi might not offer every sort of mode that *could* be desired at VHF-microwave, it's not going to receive WiFi or WBFM, but it would still be good for a lot of interesting uses.
It's not a small project but a prototype could probably be running in only a few months...
Thanks to all for ideas and suggestions. I expect to have a little more detail once we actually visit the remote site again (-2F/-19C here this morning!). In the past, the Kiwi has always restarted, so I don't suspect the power supply. On all my Kiwis I am using simple LM2596 buck converters to get from 12VDC to 5V. These have ample peak current capability such that startup has mever been a problem. In addition, once or twice in the past when on-site, the Kiwi was seen to have the "double beat" LED pattern indicating no DHCP after power was interrupted. I should have taken the "one error is a pattern" adage more seriously.
We don't know for certain but it looks from this end like the problem is one of a bridge/adaptor not coming up before the Kiwi needed it. This problem could also plague other Kiwi users, particularly anyone who might be using a WiFi adaptor as a means of eliminating all antenna feedline (and associated common mode noise currents!) by placing all the radio hardware right at the antenna. Separately I've created a very light active dipole/Kiwi/Wifi module that is light enough to be lifted by helium balloon. Such a device becomes a sort of portable e-field probe for measuring both signal and noise as a function of height and distance from residential/commercial noise sources. Perhaps more on this in another post.
I was able to scan the 169.254/16 address space using nmap (it takes a while even with only ICMP/ping probing!) but discovered only the Ubiquiti answering. A visit to the hilltop will answer the question of whether the Kiwi is actually powered and without DHCP-provided address or whether it is a power supply issue after all. This is a first test in very cold weather so anything is possible. It certainly would have been nice to have a remote power/restart control on the Kiwi. We presently have APRS delivering panel/battery/load status, separate from the microwave link, but no way to actually restart the Kiwi remotely.
Again, thanks all, I'll try to report anything else I discover that might be useful to others.
Fort Collins, CO
I think this is correct, that's how I generated these spots, by running on a moderately capable desktop. Judging from the relative performance of the KiwiSDR WSPR extension and other systems, I think asking an FT8 extension on the KiwiSDR to keep up with a band like 40m is lately is probably not realistic. I posted this in response the "Doable on the Kiwi?" question at the top of this thread. I suspect it really isn't....
My initial look only a few minutes after loading v 1.242 here is that both the ~24 Hz spurious we reported as well as the SNR degradation we saw and wrote about in the above PDF are substantially or completely gone.
It will take a more data gathering to confirm this but I'm quite confident that efforts by yourself and John have very significantly improved KiwiSDR performance, not just on WSPR but on all modes.
This is a big deal!
Thank you for all your work.
Gwyn Griffiths, G3ZIL email@example.com , Glenn Elmore, N6GN
firstname.lastname@example.org, Rob Robinett, AI6VN, email@example.comAbstract
This article is intended to document some of our recent experiences using a KiwiSDR on WSPR and observed degradations of those spots when compared with other receiving and decoding techniques. Three techniques are examined: complete decode of WSPR stations by way of the KiwiSDR WSPR extension, use of the KiwiSDR to downconvert to an audio file which is decoded by a remote host, and for contrast a non-KiwiSDR path using an Apache Angelia SDR board. These comparisons show degradations in the two KiwiSDR paths both in terms of SNR of spotted stations and in number of stations spotted. Additionally these investigations have identified spurious signals associated with the downconversion process within the KiwiSDR.
[download article PDF below]