KiwiSDR: 30 MHz Bandwidth SDR for VLF/LF/MF/HF
The KiwiSDR is an up and coming VLF/LF/MF/HF capable SDR that has a large 30 MHz of instantaneous bandwidth and coverage from 10 kHz to 30 MHz. It is designed to be low cost and used as an online internet based SDR in a similar way to how WebSDR is used, however KiwiSDR is designed to be used with the OpenWebRX software from András Retzler, HA7ILM. It uses a LTC 14-bit 65 MHz ADC and Xilinx Artix-7 A35 FPGA, and also has an integrated SDR based GPS receiver which is used to automatically compensate for any frequency drift from the main 66.6 MHz oscillator. The features of the KiwiSDR include:
- 100% Open Source / Open Hardware.
- Includes VLF-HF active antenna and associated power injector PCBs.
- Browser-based interface allowing multiple simultaneous user web connections (currently 4).
- Each connection tunes an independent receiver channel over the entire spectrum.
- Waterfall tunes independently of audio and includes zooming and panning.
- Multi-channel, parallel DDC design using bit-width optimized CIC filters.
- Good performance at VLF/LF since I personally spend time monitoring those frequencies.
- Automatic frequency calibration via received GPS timing.
- Easy hardware and software setup. Browser-based configuration interface.
The KiwiSDR is currently in beta testing and has released two OpenWebRX beta test sites which can be used at:
http://kiwisdr.sk3w.se:8073/
http://kiwisdr.ece.uvic.ca:8073/
If the software can support wfm I can run a converter and have 6 MHz of radiosondeband converted to 20 – 26 MHz. Any plans for wfm data mode ? 12 kHz ?
WFM demod should be easy I think (doesn’t WebSDR already do this?). Only question is how many channels can be supported with 12 kHz BW. Not 4 due to SPI bandwidth limits and possibly Beagle running out of cycles. Just have to try it and see.
great job , listening on line to the receiver , when can i order one ready to plug into my network or wifi ?
Kickstarter “soon come”, as they say in the Caribbean.
Working hard to drive the price down so more people will participate.
So is there a crowdfunding campaign in this SDR’s future?
Yes. Working on that now.
Thanks everyone for the feedback. I actually agree with most of your points. You can read about my design reasoning in the 60 page design document: http://www.jks.com/docs/KiwiSDR/KiwiSDR.design.review.pdf But here’s the short version: Shortwave receiver not a ham-grade receiver, lowest cost possible, plug-and-play, no PC needed, web interface, 0-30 MHz.
@Noway sdr#? Not currently. You could change things to stream IQ from a single FPGA DDC at higher bandwidth, through the Beagle, to the network. But you couldn’t do the full 30 MHz spectrum this way because there is only a 48 MHz SPI link between the FPGA and Beagle (there are connections for an un-implemented parallel port though). A second spin of the board could include a gigabit Ethernet MAC and magnetics. Then it would look very similar to Pieter-Tjerk de Boer’s WebSDR. Everything, including PCB layout, is on https://github.com/jks-prv/Beagle_SDR_GPS right now. So you could do this yourself if you wanted to.
david The second (closer) can contains the Skyworks SE4150L GPS front-end chip, not a second ADC. The LTC2248-65 costs me $28 (Q100). The absolute cheapest 14-bit solution I could find at the time. Zynx didn’t have enough FPGA resources, the ARM core was slower, and cost more (at the time) than Artix-7 A35T ($34) + BeagleBone ($55, or now $39 with BB Green). The poor Beagle runs flat out at 1 GHz, barely keeping up with those 8 DDCs. The GPS is all open firmware from Andrew Holme: http://www.aholme.co.uk/GPS/Main.htm I don’t know if the SD-GPS could ever be the basis of a GPSDO. There is a connector on the board so you can bypass the GPS TCXO and use a more stable reference. The problem is the unknown characteristics of the L1 PLL in the Skyworks front-end chip. Is it good enough for a GPSDO? Does it even matter? I don’t know the answers yet. Maybe someone else can figure it out. The GPS is included solely so people can experiment and learn how GPS works by changing the Verilog and C++ code and as a way of correcting the frequency offset of the cheap ADC clock. I learned all about GPS this way (well, legacy GPS anyway). It was a fantastic experience.
@Adam david No programmable attenuator, fixed-gain non-switchable preamp, no noise-blanking switch, no sub-octave filtering, questionable noise-figure. Yep, agree with all that. But remember the goals: dirt cheap, shortwave receiver. Now listen to the beta test receivers and also P.T.’s WebSDR since it has a similar front end (although 16-bit ADC). Works okay if you ask me. An earlier version of the UI had a built-in WSPR decoder and it used to decode QRP signals from Europe here in New Zealand no problem. But sure, it’s no match for the $600-$3500 SDRs or ham receivers.
Price: Yeah, trying to figure that out now. I would guess US$250 +/- $50. The BOM Q100 is $130 assembled and tested. Trying to get that down to $100. But the hardware cost isn’t nearly as important as everything else: distribution, fulfillment, return/repair margin, certification… That list is endless. And it determines if you’re a success or go broke. And you have to figure it out early because if the retail price is lower after the Kickstarter people get upset. They shouldn’t, but they do. If I could somehow skip the nonsense that’s about to happen I would. I’d much rather get back to writing these neat applications I have in mind once there are a bunch of these things distributed world-wide.
Here’s the rule for successful designs: Use expensive parts only in high end (high value-added) designs. For all the rest, use simple designs and engineer everything so it performs decently.
What you are doing here is the complete opposite: You are using expensive parts in a cheap design. Not good.
I’d agree with that principle. But I’d disagree that’s what I did considering the requirements. That 14-bit, 65 MHz ADC is $27. Cheap compared to the 16-bit versions that run $70+. 8 and 12-bit ADCs don’t work in the design. The mid-range FPGA I use is $34 through distribution. I’m negotiating to get it for a lot less. WIth 8 DDCs (4 receiver channels) and 12 GPS channels the logic fabric is 60% used, the on-chip memory 96%. So I can’t use a smaller part. Everything else is jellybean: nothing over $3.50 and only 5 parts over $2. BOM is on Github if you’re interested. But, it’s all relative. That beautiful ultra low-noise ADC VCXO all the big boys use? $30. My acceptable phase noise XO whose terrible +/-50ppm frequency stability is completely corrected by the GPS for “free” since it was going to be on the board anyway? $2.
So, yeah, from a mass-market RTL perspective you are absolutely correct. From the $600-$3500 performance SDR perspective I look like a fail. But wide-band, web-enabled, plug-and-play for $250? I’m hoping that has some appeal. Anyway, I sincerely appreciate any and all feedback because this is a learning experience for me as much as anything. Cheers, John.
At the price of the BOM, better add some goodies that are still inexpensive for you to implement but give your potential customers a good reason to spend $300 ~ $400 on a good radio.Below that price range, you are basically destroying value.
Of course, it will be a whole different story if the BOM was like $30. Just saying. Good luck!
I am ready to purchase.
When will these be available?
Thank you.
Bill Kisse
hmm does it work with sdr#?
Since it is a “cape” for a BeagleBone Black, and it only accessable through it’s web interface. I would guess no.
Why the two LTC2248 (I presume they’re in the two cans, one for I & one for Q, or maybe one can is the GPS front-end) instead of one LTC2298 with two ADC’s on-die? Is there an isolation problem? You could probably chop a nice chunk of change off your BOM with the LTC2298 (approx. $50 vs. 2x$40 in small qty.) I presume you looked at the Zynq when you went down this road, right? Zynq has an ARM core on it already. I like the GPS core, is it open or proprietary IP? If you can get the GPS thing to output a low-jitter GPS referenced NCO output (or at-least a low-jitter 10MHz fixed reference), I bet you would sell a bunch of these just for disciplining radios, test equipment, cellular base stations, you name it! Even if you can’t get the NCO output clean enough, clock cleaners are pretty cheap. Is there a switchable pre-amplifier for the higher-frequency bands? Is there a switchable attenuator for the low frequency bands? If-not, I guess it could be kludged externally and controlled via the Beaglebone, but I’d really like to see a user controlled pre-amp and attenuator on-board. Noise-blanking is a sorely missed feature on SDR’s like this, please implement it. Remember your front end is as wide as a barn door, noise blankers can help with dynamic range too in tough environments (e.g., crappy LED lighting everywhere). Finally, what is it going to cost just for the SDR board? Glancing at the schematic I’m seeing roughly $200 in parts cost alone with the board and connectors, That’s before assembly and test. So maybe a $300-$400 sell price?
You did not check the diagram? 🙂
Just a 30MHz LPF at the input, no ATT, no switchable AMP, frontend is LTC6401 20dB fixed gain but high IP3 device.
GPS is driving 16.368MHz TCXO not so common reference as 10MHz.
Interesting radio…
Shut up and take my money 😀
Hope Kickstarter start soon
Thanks for the plug. A few things to note: This is an add-on board (cape) for the Beaglebone Black. Although I started with the OpenWebRX software as the basis for my user interface, I am not compatible with what Andras currently distributes for use with RTL-SDRs. Right now we’re trying to figure out how to produce SDRs to sell. A Kickstarter is under consideration.
Congratulations, nice hardware and implementation! 😉
Nice GUI and overall impression. I check the Sweden websdr and noted audio and waterfall time gap, audio is a few seconds late. The same problem on the Canada based radio. Strange behavior. Firefox here.
Yes, the audio buffer sizes are currently large (hence the several second delay from real-time) because the code to deal with varying network latency isn’t very sophisticated yet. WebSDR does a fantastic job of this with a very clever algorithm. But they are currently closed-source so I have to use a different technique. This problem should get better in the future.