Use this space to cheer the creator along, and talk to your fellow backers.
Have a question?
Thanks will do!
libbladeRF uses libusb which should run on a Beaglebone Black without any issues. If you have any questions or issues getting it to work you feel free to ask on the forums or on IRC!
Has anyone attempted or had success in getting the board communicating with a Beaglebone Black? I came across this and it looked interesting http://www.rtl-sdr.com/portable-homemade-spectrum-analyzer-using-a-beaglebone-black-and-the-rtl-sdr/ as well as a lot of info located here:
I'm going to give it a shot and also ping the BladeRF forums.
Gil: Aside from the frequency range, also consider these spec differences: 8-bit half-duplex 20MHz vs 12-bit full-duplex 28MHz bandwidth. Onboard CPLD vs Onboard FPGA (up to 115kLE). USB 2.0 vs USB 3.0 host interface. The bladeRF's frequency support is largely defined by the LMS6002 chip it uses. However, a transverter daughterboard to widen the frequency range is in the works.
Disclosure, i'm a backer of both projects.
The hackRF project has a frequency range of 30 MHz - 6 GHz and with a Ham It Up the low end of the range is 300 kHz. Other than that however BladeRF has better specs. Any chance of a BladeRF version with a wider frequency range, and can BladeRf work with Ham It Up?
For all those wondering, there is Kickstarter upgrade category that will let you upgrade your reward tier at the Kickstarter difference.
Follow the link to http://www.nuand.com/blog/product/bladerf-x115-kickstarter-upgrade/
Tracking numbers will be emailed the day the order is shipped. Most international orders will be shipped via USPS, and almost all domestic orders will be shipped with Fedex.
Robert Ghilduta can you please check your email and messages here!
Have sent two messages for you and have yet to hear back from you. Would appreciate it if you could get back to me as soon as you have a spare moment.
Can we expect tracking numbers and/or a shipment notification, or will the radio just show up?
Is it possible to upgrade to the larger FPGA?
Whole-Home Gesture Recognition Using Wireless Signals
Thanks for the fast reply! 30.72 will be fine for the most demanding LTE bandwidth (20 MHz). As for GSM any multiple of 0.270833 should do I guess.
We've placed a Silicon Labs Si5338 clock generation chip down to control the ADC/DAC clocks. It's being fed with the fundamental 38.4MHz VCTCXO reference, but it can be programmed to synthesize most any frequency you'd like.
The maximum sample rate on the ADC/DAC for the LMS6002D is 40MHz so we are not able to do 52MHz or 61.44MHz, but we can do 26MHz and 30.72MHz. Furthermore, there are also programmable baseband low pass filters to further limit your incoming bandwidth in the analog domain before you sample it.
It's great to see this project move forward as planned!
On interesting characteristic of the USRP B100 is the adjustable clock - for instance, it can do both 52 MHz (useful for GSM) and 61.44 MHz, useful for both UMTS and LTE. Will bladeRF have this capability also? Or will resampling be needed on the host or the FPGA?
I'm also in line with the guys that would want a connector with a few LVDS lines. In my case I would want to connect a daughter board with an SATA port (for data collection) in one case. My second use case would just be a connection to some ADC/DAC for audio applications.
Though the SATA idea would be the one I'm really interested in, mainly because of the USB3 & the big FPGA. Would be a great development board for my project.
USB 2.0 has significantly different throughput capabilities than USB 3.0, the most important distinction besides throughput though is the fact that USB 2.0 is half-duplex. We don't have exact numbers for USB2.0 throughout just yet, primarily because USB 2.0 throughput varies significantly even between host controllers. We realize that throughput will be an issue with USB 2.0 hosts, as a solution we're looking to implement waveform compression cores for the raw RF sample transceiver mode as well as hardware modulators/demodulators for what we call "modem mode."
There is a mention on your website regarding USB 2.0 backward compatibility for embedded applications.
It is clear that the difference in transfer rates, will introduce constraints.
Since all the specs presented are for USB 3.0, do you have any benchmark results for USB 2.0 (e.g, maximum channel bandwidth, achievable sampling frequency)?
The bladeRF and the product line will absolutely continue after the Kickstarter. And yes, both versions of the bladeRF will be available via our webstore or a reputable distributor. However, we aren't sure about the post-Kickstarter pricing just yet, we hope to announce that shortly.
Thanks for the MIMO option guys!
To add onto Montezuma's question, any idea what the post-Kickstarter pricing will be for the 15K and 115K boards?
Firstly, my apologies if this has been asked and answered here(if it was, I overlooked the question and answer(s)), or if this has been covered elsewhere, but...
Will these SDRs be available for purchase after the funding is achieved, and will 15KE and 115KLE FPGAs both be available, or, at the very least, only the 115KLE FPGA? I ask because achieving funding doesn't necessarily mean products will becomes available, nor that any products will be available for sale afterwards. I also want to purchase two of the 115KLE FPGA boards, but after all of the funding I have put into furthering my ammunition and firearm collection, as well as my purchases of a few Raspberry Pis, some breadboards, breakout boards, other electronic equipment and parts, as well as my funding of this project, two boards would mean a likely lifetime couch sentence from my warden(girlfriend).
I have some big ideas for my first bladeRF, and I am in the group of people that want, at minimum, two boards, if not four. So, I would feel better about holding off, until I can clear my most recent buying spree, and make plans for hiding the purchase of another board, or three, a little later(which would be next month, possibly April, at the latest). While one could possibly assume that the creators of this project intend to build a business plan to sell these boards from the point of funding, and forward, I prefer to not assume, but rather verify.
So, will these boards be available for purchase after the funding period expires, through either Nuand's future "webstore", or some third-party supplier channel(s)? I understand that supply availability would be at some point after project backers have our initial boards shipped. I do understand that. So, given that understanding, I am interested in any answer, even if it is subject to future change(which I also understand).
Due diligence was done on the design. IBIS models were either downloaded or created for the 4 major ICs (FX3, Cyclone 4, LMS6002D, Si5330) to verify that no significant impedance mismatches existed on any trace operating at >10MHz. The power supplies and power planes underwent Power Distribution Network (PDN) analysis for voltage ripples, decoupling, plane impedance as it relates to current draw, and power efficiency. Lastly, the layout of every high-speed (>400MHz) and analog RF trace was verified and tuned using a 3D EM field solver.
You mean a dB saved is dB earned. ;-)
@Benji, thanks for answering the layout software question! As for controlled impedance, typically the soldermask (or stopmask as some people call it) is pulled back along RF traces. The trace width is sometimes noticeably different as well. However, doing some quick calculations since you asked, I'm guessing around a 10 mil trace width for a 50 Z0. This is assuming an 8 layer FR4 board with a 62 mil finished thickness. Looking at close up pictures, the traces from the SMA connectors could very well be near that. For me, I'm just wanting to be sure that all bases are being covered, since an SDR covers so much EE theory (pretty much every aspect). A dBm saved is a dBm earned, if that's how the saying goes...
@Jack B, judging from the few images they've posted I'm fully confident that good design practices are being followed including controlled impedance.
On a side note, how can you tell if controlled impedance is (not) being used without seeing the trace width, board stackup and fabrication notes?
Finally some Cadence layout on kickstarter!!!
Great job so far on your design work. It looks like you all have been, "in the saddle" before. Out of curiosity, what program are you using for board layout?
On the technical side, I have questions regarding the RF front end. It doesn't look like the traces going from the balun to the SMA connector are controlled impedance. Is there a reason for this or am I not seeing something? Also, will we see some impedance / reflection (w.r.t. 50 ohm) plots over frequency for the Tx/Rx ends? Lastly, the limemicro datasheet makes reference to PA driving pins. How are those going to be implemented on the board for use?
We are compiling a list of jitter and signal quality measurements as we speak. The main issue with the 15KLE vs the 115KLE FPGAs is that doing buffering and scheduling on the larger FPGA is much easier since there are a lot more M9K memory units. That being said, we are first going to get OpenBTS working with the larger FPGAs then see what has to be done buffering wise to get it to work with the smaller FPGA.
Nuand, the questions around the FPGA and OpenBTS have confused me, can the $400 bladeRF be used in the creation of a GSM air interface, that was something I wanted to play about with?
I'm crossing my fingers to see what it's going to be. The Cyclone 4 data sheet lists +/-300 ps of period jitter at 100 MHz for the dedicated PLL output, unless I'm reading it wrong (they don't specifically list the cycle-cycle jitter). However in some other data sheets period and cycle-cycle are equivalent. Optimistically go with 100 ps RMS jitter on a 40 MHz clock, which is 5 ENOB or 40 dB SNR. Please do a few FFT plots (maybe 256 and 16384 lengths) at low and high frequency (baseband) tones. I'd just hate to loose all that dynamic range when a $10 clock synth (ditch the SMA cables) could improve it significantly.
Sylvain, Rowan, Martin,
There's going to be an unpopulate SMD .1" header underneath the board. Getting LVDS is kind of tricky because of its 2.5V requirement. The only problem here is that our 2.5V source is in an analog power domain so we need to see what we can do to avoid having digital signals directly share the same reference rail.
The analog pins are already available for use, their form factor is slightly different from the main expansion board header, however it should be possible to design a board that fits over the main and analog connectors.
The 15KLE FPGA acts mostly as glue logic between the USB 3.0 microcontroller, the RF trasceiver, the expansion board slot, and all of the other peripherals. Although we are not convinced it's impossible to get OpenBTS working on the 15KLE FPGA with many clever tricks and careful buffering techniques, we are focusing our OpenBTS and Open Source LTE Deployment (OSDL) development for the larger version. Also, we will release our lab experiments shortly (before the weekend) so you can get an idea about the impact of the current design's jitter on SNR. For the pre-production spin, we are rerouting the LMS's sampling clock source to the FPGA's dedicated PLL output pins which are much lower jitter.
Got a few few questions:
Can you comment on the % utilization of the 15K FPGA and what's going on inside? I assume something like OpenBTS would require the 115K (which may lead me to bump my pledge).
I see the RX clock is sourced by FPGA. Is the RX clock rate fixed and the samples decimated within the FPGA, or RX clock synthesized within the FPGA? For the latter case, is the jitter low enough to preserve the 12 bits of the ADC? I think 12 bits at 40 MHz would require 0.7 ps RMS jitter.
In addition to GNU Radio, I'd also like to see an HDSDR ExtIO driver.
@Nuad: wrt to GPIO, I think it should support exporting / importing the full bandwidth, so 2 * 2 * 12 * 38.4M ~= 1.9 GBps
Any unrouted pin is a pin wasted.
Just like the others, I'd be very happy with as many externally accessible GPIO and interface pins as possible! :)
sorry I am new to this (SDR), and by accident when surfing at www.zedboard.org, I stumbled accross this accessoir:
This seems to be an add-on to the Xilinx Zyng 7020 FPGA develeopment board, ad an astonishing price of USD 2.495,00. But they state it is based on the same LMS6002D transceiver IC the bladeRF is using - and the bladeRF has the FPGA already "included".
So can anyone be so nice to point out the differences? Is there anything included what is "missing" on the bladeRF?
Would this mean the bladeRF is a real "bargain" when wanting to start in the SDR field?
On the other side, if I see it right blade RF is "the transceiver IC, the FPGA, and and USB interface" (in short words) for the pledge of USD 400,00.
I backed another kickstarter project, the parallela board, including Zyng 7020 FPGA, epiphany 16 core chip, and all major interfaces, for USD 99,00. So wouldnt that mean that this "hardware base" would only need a "shield" with the transciever IC to be at lease of similar functionality as the bladeRF at an interestingly low price point?
Sorry for that confusing questions, maybe someone familar to SDR hardware/software requirements/overview can give his thoughts on this.
That having said, what would be the applications someone would need the larger FPGA?
A more concise way to put all of that is give us as many pins as routing and signal integrity allow! One way or another, I'm looking forward to playing with this thing :D
Nuand, I initially had in mind expansion of the ADC/DAC capabilities. But in practicality, I think that it would be vital to have enough pins to control extensions of the RF front end to other frequencies, as well as ensure that hardware could be added for PC independent operation. I think that a 16 bit LVDS buss with some extra control signals would be cool in the case of data converter expansion, a CPLD could be used on the daughter board to break this out to multiple data-converters. But more pins would make life easier. This probably goes beyond the scope of this project though. Some DDRx ram might be a cool addition as well.
Thanks Nuand, any reason why you mention differential probes is it because of usb using mains ground?
If so powering it from a floating PSU could remove the differential probe requirement?
Signals received by the bladeRF are digitized and sent to the host PC, where you can post-process them and represent them in whatever way you want. That of course will require you to use either GNURadio or your own visualizer. However, if you really wanted to use a physical oscilloscope, there currently are baseband I and Q pins that go to headers. You could use a 2 channel oscilloscope with differential probes to visualize the quadrature representation of the received signal.
Sylvain and Jack,
We have been looking into bringing out a couple more LVDS pins to an unpopulated SMT header on the bottom of the board. Is there any particular throughput or application you have in mind so we can best plan this out?
Cool project, and funded!
I have a question, basically say I wanted to examine radio modulation schemes with an oscilloscope, is there a way to output the signal received by the bladeRF to an oscilloscope?
I'd like to second Sylvain Munaut's proposal for a de-poped high speed connector for a daughter board. It seem to me that adding as high speed parallel buss would greatly improve the expandability of the bladeRF hardware, especially in the case of the high gate count FPGA.
I like the antenna, are they included?
Or where can i buy them?
Best regards to a great project.
As there is some time to go can I ask that you investigate the customs declarations you will be using for international shipping. I have purchased boards from the USA before and been stung with 20% tax instead of 3% for electronics assemblies. Checking myself I believe the bladeRF could be construed as a component or assembly of a larger system because it comes without a case, the inclusion of the USB3 cable may actually cause problems with the customs authorities because they may view it as "finished goods" and tax it accordingly. 20% of $400 is a great deal of money and if the regulations permit there is no need to pay the extra duty.
Small requests for further board revisions: more GPIOs :)
The 16 bit port on pin header is fine for "low bandwidth" application and extension board or to control a few external parts. But if you're trying to ship samples to an external board (think parallella) where USB3 is not an option, then having a high speed connector would be useful.
I think in that case, given the limited audience, it would be allright to just have an unpopulated high density smd footprint on the board with GPIOs routed as LVDS pairs.
wrt to USRP comparaison. I would say that the Ettus boards might have better raw RF specs. The higher sample rate allows for more decimation gain, also higher #bits per ADC allow for more dynamic range. The separate RF boards also allows them to have board with better & narrower RF filter to lower the chance of input overload. So all in all, I see the USRP as being more high perf lab instruments.
Now, the BladeRF specs are still very good and will be even overkill for most people and it's lower price point definitely fills a gap in the market IMHO.
I would also like to point out that Ettus is a big contributor to GNURadio which is not specific to their HW and I hope that Nuand will also dedicate resources to work on things that are not specific to their HW.
Just my 2ct.
@Al: I asked Nuand a similar question in a PM. Since I wanted to compare it closely on a cost-sensitive POV, I asked for a comparison with the Ettus B100. Here's the summarized answer (hope Nuand doesn't mind the direct quote):
"The B100 uses 64MHz ADC/DACs which are then filtered to a bandwidth of around 8MHz quadrature samples which are then transferred over USB 2.0. bladeRF uses ADC/DACs which are capable of a maximum of 40MHz quadrature sampling which are inside the LMS6002D RF transceiver. Those samples can immediately be shipped over the USB 3.0 superspeed connection at the full rate."
"Moreover, the B100 accepts daughter boards for tuning the frequencies whereas [bladeRF's] RF transceiver is built into the main board. You can extend the range of the device with other boards, but it isn't required if your signal of interest happens to fall within 300MHz - 3.8GHz."
"Another difference is the bus powered nature of bladeRF versus the B100. We have a DC jack available if you need the extra power for other peripherals, but the design was intended to be fully functional off just USB bus power - no external DC required."
This technical differentiation is, imho, enough justify bladeRF as a unique product with meaningful improvements vis-a-vis the basic Ettus units, and that's before talking about the difference in price or the smaller form factor.
Paul, regarding the bandwidth, there are some cool things one can do with that much bandwidth. With the USRP2 and GNU Radio I am able to capture half the 2 meter band and stream N channels of NBFM audio to disk (N is limited by processor and BW and I can do N=5 easily). Channels are gated to only record when active. Things like cross channel repeating is simple.
Al, it's the price. The USRP2 is $1200 which would have the equivalent BW, then another $450 for the WBX. The main part of the USRP cost is probably the ADC through to the front end daughter card. That's probably $700 to $1000. These guys are using a $70 chip with almost the equivalent; the 300 MHz limitation and IIRC 12 bits instead of 14. The USRP is a very nice piece of engineering, but this will open things up to allot more people since it is $400 instead of $1600.
Although I like the project, it looks like much less of a product to the excellent work of Matt Ettus in producing an open platform open source product with better characteristics. I imagine you are familiar with him and I wonder if you can comment on the differences to better help me understand why you see this as a necessary effort or why you feel that you will eventually surpass some aspect of his work and the open community around his work.