The PSDR is a cool kit; I'm glad it had the Cinderella Story and met the funding goal in the last few hours.
I've been working on the Whitebox project since before the PSDR; None of the kickstarter SDRs existed when I started my project... The reason why I'm taking longer to launch is that our design is going to be legal to transmit with amplification; and have a fully fleshed out receive chain. This is a tall order to achieve, but we're getting close.
I'm not releasing this design under a 100% Open Hardware license (No gerbers, No project files). There will be a very detailed service manual with schematics and description of how the device works, like a Heathkit manual. To advance the hobby, I want to explain to everyone how a device like this works, and what Sound Engineering means in practice when building a transceiver. Giving someone Gerbers doesn't teach them these things.
No components in the design are under an NDA, and the board has LOTS of test points, so it should be very possible for the homebrew ham to modify the board to their heart's content.
All of the source code (FPGA, ARM uClinux, smartphone Android) is already up on github with an Open Source license. One part, the cellular-lockout gateway will not be Open Source. This is so that way we can actually sell the device as Amateur/Commercial equipment, not just test equipment.
I originally wanted 100% Open Hardware, but the business model doesn't work well with the FCC. It's taken me time to accept that. I chose to work with Bruce because he's an expert on how to get commercial entities to work with Open Source. If there's a chance that we could actually move to more Openness in type safe transceivers, this is a good next step to make.
The receiver has a block on certain cellular frequencies in the 800MHz band. This is the only restriction. The radio can tune to any frequency between 50MHz-1000MHz, otherwise.
To get optimal performance, you do want to have an appropriate bandpass filter in the filter bank (you can set 4 bandpass filters). They can be swapped by you to get good performance on whatever band you care about.
I have the utmost respect for the Sport of Ham radio on HF; but I built this device with a different intention in mind vs competing for DXpedition mind-share. VHF/UHF radios are the workhorse of modern communication, and my goal is to experiment with what you can do there. The possibilities are very different between 6m, 2m, 70cm, and 23cm (for instance). Transverters with a HF SDR are a viable option, but not for your pocket, yet.
To answer your question about connectivity, the device has 10/100 Ethernet with the Linux networking stack built in. It also has USB-OTG, and I already know WiFi and USB Sound Cards work with no additional work.
You do if you'd like to directly convert your model, which works so well at the high level, into C or RTL. Yes you can rewrite your Octave script in Verilog, but part of what makes MyHDL exciting is that this extra work is done for you.
I agree that the essence of RTL isn't too difficult; the complexity arises when you use RTL to do filtering and modulation. Even the vendor tools are lacking when it comes to analyzing Digital Signal Processing. You have to use Simulink, and that's not a cheap proposition.
I would say that the main advantage of using Python is in the verification process - writing test fixtures and analyzing the results of simulations is much easier to do with the Python toolkit. Design of real world Digital Signal Processing for the FPGA feels much more natural.
In the end, All simulations end up running in a real Verilog simulator, after conversion. I use Icarus Verilog and it integrates seamlessly at this point. You can tie in your own Verilog modules too.
This is one of the most interesting and challenging questions to answer. Here's a blurb excerpt from Eric Blossom, an early innovator in software radio as to why this stuff is so valuable:
"Software radio is a revolution in radio design due to its ability to create radios that change on the fly, creating new choices for users Perhaps most exciting of all is the potential to build decentralized communication systems. A centralized system limits the rate of innovation. We could take some lessons from the Internet and push the smarts out to the edges. These user-owned devices would generate the network. They’d create a mesh among themselves, negotiate for backhaul and be free to evolve new solutions, features and applications." - Eric Blossom, Exploring GNU Radio
What's exciting is now a radio, which has the "brains" to be a major part of Internet infrastructure (think Veriozon's cell towers everywhere) will fit in your pocket. This should enable a change in the landscape of the Internet itself, and I hope it frees our comms from bondage to wire's and large multi-national corporations.
Chris Testa KD2BMH here. marid, your suspicion is correct, the CMX991 transceiver I'm using has a low-end cutoff of 100MHz.
The HF converter w/ a NE-602 mixer in the latest QST looks like an attractive solution to support the missing lower frequencies receive, I'm guessing 2 would allow me to build a full duplex transceiver.
I'm using a 40MHz ADC & DAC, so at least some of the HF bands should be possible using direct conversion.
Either way, HF wasn't part of my initial plan, I'm focusing on exactly what I can fit inside easily, and then more features can be added later. Launch & iterate... the kitchen sink will come in one of those iterations:)
I've seen a lot of hating on the Semantic Web the past few weeks, but a lot of support when things like this come out. If you check out the definition of the Semantic Web, you'll find:
The Semantic Web provides a common framework that allows data to be shared and reused across application, enterprise, and community boundaries.
This is exactly what NOAA did with their weather data. It is a common misconception that the Semantic Web is supposed to be some gigantic cross-reference, or that AI weenies think it will solve all of our problems. Imagine a web where everyone publishes data in a common format, and everything can be re-used. Want to drop weather data into your app? Just add a few lines of code. Now that's powerful.
As far as my theature went, we had NO previews or commercials, which was an incredibly pleasant suprise. No one could believe it when the LoTR logo came up right away - needless to say it generated a huge applause.
Slashdot Mirror
The PSDR is a cool kit; I'm glad it had the Cinderella Story and met the funding goal in the last few hours.
I've been working on the Whitebox project since before the PSDR; None of the kickstarter SDRs existed when I started my project... The reason why I'm taking longer to launch is that our design is going to be legal to transmit with amplification; and have a fully fleshed out receive chain. This is a tall order to achieve, but we're getting close.
Testa KD2BMH
I'm not releasing this design under a 100% Open Hardware license (No gerbers, No project files). There will be a very detailed service manual with schematics and description of how the device works, like a Heathkit manual. To advance the hobby, I want to explain to everyone how a device like this works, and what Sound Engineering means in practice when building a transceiver. Giving someone Gerbers doesn't teach them these things.
No components in the design are under an NDA, and the board has LOTS of test points, so it should be very possible for the homebrew ham to modify the board to their heart's content.
All of the source code (FPGA, ARM uClinux, smartphone Android) is already up on github with an Open Source license. One part, the cellular-lockout gateway will not be Open Source. This is so that way we can actually sell the device as Amateur/Commercial equipment, not just test equipment.
I originally wanted 100% Open Hardware, but the business model doesn't work well with the FCC. It's taken me time to accept that. I chose to work with Bruce because he's an expert on how to get commercial entities to work with Open Source. If there's a chance that we could actually move to more Openness in type safe transceivers, this is a good next step to make.
Testa KD2BMH
The receiver has a block on certain cellular frequencies in the 800MHz band. This is the only restriction. The radio can tune to any frequency between 50MHz-1000MHz, otherwise.
To get optimal performance, you do want to have an appropriate bandpass filter in the filter bank (you can set 4 bandpass filters). They can be swapped by you to get good performance on whatever band you care about.
Testa KD2BMH
I have the utmost respect for the Sport of Ham radio on HF; but I built this device with a different intention in mind vs competing for DXpedition mind-share. VHF/UHF radios are the workhorse of modern communication, and my goal is to experiment with what you can do there. The possibilities are very different between 6m, 2m, 70cm, and 23cm (for instance). Transverters with a HF SDR are a viable option, but not for your pocket, yet.
To answer your question about connectivity, the device has 10/100 Ethernet with the Linux networking stack built in. It also has USB-OTG, and I already know WiFi and USB Sound Cards work with no additional work.
73,
Testa KD2BMH
Hey Jan, thanks for making MyHDL :D
You do if you'd like to directly convert your model, which works so well at the high level, into C or RTL. Yes you can rewrite your Octave script in Verilog, but part of what makes MyHDL exciting is that this extra work is done for you.
I use Verilog as Verilog, and Python as SystemVerilog.
Type checking is done at simulation time, and ultimately during synthesis. Duck typing is immensely useful for higher level abstractions.
Chris KD2BMH
I agree that the essence of RTL isn't too difficult; the complexity arises when you use RTL to do filtering and modulation. Even the vendor tools are lacking when it comes to analyzing Digital Signal Processing. You have to use Simulink, and that's not a cheap proposition.
Chris KD2BMH
I would say that the main advantage of using Python is in the verification process - writing test fixtures and analyzing the results of simulations is much easier to do with the Python toolkit. Design of real world Digital Signal Processing for the FPGA feels much more natural.
In the end, All simulations end up running in a real Verilog simulator, after conversion. I use Icarus Verilog and it integrates seamlessly at this point. You can tie in your own Verilog modules too.
Chris KD2BMH
Thanks no_such_user... see you at Dayton! I'll hopefully be helping out at the TAPR booth.
73,
Testa KD2BMH
Chris Testa KD2BMH here...
This is one of the most interesting and challenging questions to answer. Here's a blurb excerpt from Eric Blossom, an early innovator in software radio as to why this stuff is so valuable:
"Software radio is a revolution in radio design due to its ability to create radios that change on the fly, creating new choices for users Perhaps most exciting of all is the potential to build decentralized communication systems. A centralized system limits the rate of innovation. We could take some lessons from the Internet and push the smarts out to the edges. These user-owned devices would generate the network. They’d create a mesh among themselves, negotiate for backhaul and be free to evolve new solutions, features and applications." - Eric Blossom, Exploring GNU Radio
What's exciting is now a radio, which has the "brains" to be a major part of Internet infrastructure (think Veriozon's cell towers everywhere) will fit in your pocket. This should enable a change in the landscape of the Internet itself, and I hope it frees our comms from bondage to wire's and large multi-national corporations.
This was my original inspiration, at least.
Here's the paper published in the TAPR DCC conference proceedings: http://www.tapr.org/pdf/DCC2012-Handheld-Software-Radio_KD2BMH.pdf
Also, follow me on twitter http://twitter.com/testa or my blog http://blog.testa.co/
Chris Testa KD2BMH here. marid, your suspicion is correct, the CMX991 transceiver I'm using has a low-end cutoff of 100MHz.
The HF converter w/ a NE-602 mixer in the latest QST looks like an attractive solution to support the missing lower frequencies receive, I'm guessing 2 would allow me to build a full duplex transceiver.
I'm using a 40MHz ADC & DAC, so at least some of the HF bands should be possible using direct conversion.
Either way, HF wasn't part of my initial plan, I'm focusing on exactly what I can fit inside easily, and then more features can be added later. Launch & iterate... the kitchen sink will come in one of those iterations :)
Hats off to the coder who blamed on that one. You've made history!
This is exactly what NOAA did with their weather data. It is a common misconception that the Semantic Web is supposed to be some gigantic cross-reference, or that AI weenies think it will solve all of our problems. Imagine a web where everyone publishes data in a common format, and everything can be re-used. Want to drop weather data into your app? Just add a few lines of code. Now that's powerful.
As far as my theature went, we had NO previews or commercials, which was an incredibly pleasant suprise. No one could believe it when the LoTR logo came up right away - needless to say it generated a huge applause.
giFT (http://www.giftproject.org/) is working on an open source implementation. Details will come soon (and everyone is welcome to help!)
-Chris