What is the maximum possible instantenous bandwidth of the data transferred over USB (for recording purposes)?
I think I've arrived at 40MHz sample rate * 12 bits * 2 (I/Q data) = 120MByte/s per direction ... am I far off?
Would there be issues with multiple bladeRFs to a single computer (besides that you'd need a massive computer to save it all)? Thinking of trying to examine the entire 2.4GHz ISM band, so that's 4 bladeRFs (aside, is there the notion of a master/slave in the clock SMA connector?)
Thanks.... waiting to get started soon with it.. I hope!
Data transfer bandwidth?
-
- Posts: 303
- Joined: Mon Mar 04, 2013 4:53 pm
Re: Data transfer bandwidth?
You're right on target with your bandwidth calculation and your beefy computer required. You don't necessarily need them connected to the same PC, though. You could potentially have them connected on disparate computers, process/save the data, then bring all the results together at a much more decimated rate.
As for the clocks, yes - there is a notion of a master and slave. The clock SMB can either be the input to the Si5338, or be driven by the Si5338. This will be exposed by the software. Also note that you can make all your bladeRF's slaves, and supply an external 38.4MHz reference to all of them. It's just the reference - there isn't anything special going on between them. To synchronize them further, there is a mini expansion header which is meant for a 1PPS signal or other trigger signals. Be sure to check the schematic.
Hope that helps!
Brian
As for the clocks, yes - there is a notion of a master and slave. The clock SMB can either be the input to the Si5338, or be driven by the Si5338. This will be exposed by the software. Also note that you can make all your bladeRF's slaves, and supply an external 38.4MHz reference to all of them. It's just the reference - there isn't anything special going on between them. To synchronize them further, there is a mini expansion header which is meant for a 1PPS signal or other trigger signals. Be sure to check the schematic.
Hope that helps!
Brian
-
- Posts: 6
- Joined: Fri Mar 01, 2013 3:25 am
Re: Data transfer bandwidth?
Thanks for clarifying that.
What is the purpose of J55/SMA on page 3 of the schematic, connected to the FPGA? Is that a left over from when it was going to use the PLL of the FPGA, but then got moved over to the Si5338? Or is it (supposed) to be used to synchronize the clocks of multiple FPGAs?
What is the purpose of J55/SMA on page 3 of the schematic, connected to the FPGA? Is that a left over from when it was going to use the PLL of the FPGA, but then got moved over to the Si5338? Or is it (supposed) to be used to synchronize the clocks of multiple FPGAs?
-
- Posts: 303
- Joined: Mon Mar 04, 2013 4:53 pm
Re: Data transfer bandwidth?
We put J55 there with the idea that the FPGA could tame the VCTCXO using a 10MHz 1.8v LVCMOS clock signal. Maybe something coming from a house standard or GPSDO that was external that could feed multiple units.
Inside the FPGA, we would take the 10MHz (or whatever the reference frequency is) and divide it down by some amount. We would then also count the number of normal 38.4MHz ticks that happen in the same time. Knowing how many ticks should have happened in the time interval should give us a feedback mechanism to the VCTCXO DAC to tame the VCTCXO.
We are planning on keeping the SMA unpopulated for production since not a lot of people need that functionality and SMA connectors are somewhat expensive. We also don't terminate or do anything else with the clock - all conditioning has to be done externally.
Hope that helps. Let me know if you have other questions.
Inside the FPGA, we would take the 10MHz (or whatever the reference frequency is) and divide it down by some amount. We would then also count the number of normal 38.4MHz ticks that happen in the same time. Knowing how many ticks should have happened in the time interval should give us a feedback mechanism to the VCTCXO DAC to tame the VCTCXO.
We are planning on keeping the SMA unpopulated for production since not a lot of people need that functionality and SMA connectors are somewhat expensive. We also don't terminate or do anything else with the clock - all conditioning has to be done externally.
Hope that helps. Let me know if you have other questions.
-
- Posts: 6
- Joined: Fri Mar 01, 2013 3:25 am
Re: Data transfer bandwidth?
Interestingly it seems that the actual range of the low pass filter can be influenced upward by 50% by careful manipulation of TRX_LPF_CAL - meaning that you could actually receive an unfiltered 40MHz bandwidth, if you had a very good bandpass filter in front of the device, or were willing to accept aliasing, or maybe just wanted a couple extra MHz for what it was you were doing ....
Do the TXD[0:11]/RXD[0:11] pins clock at 80MHz? I can't find a definitive "Maximum TX_CLK/RX_CLK/bus pin frequency", although it used to claim an absolute maximum speed for the data converters of 50MHz (probably at a price of increased noise.)
I bet it would get really hot, clocking the data converters at 50MHz each while having the low pass filter configured at 40MHz, and probably wildly out of spec RF.
That 50MHz figure was in the old datasheet dated 3/5/12, not the newer ones. I bet it would still work, though. One can dream.
Do the TXD[0:11]/RXD[0:11] pins clock at 80MHz? I can't find a definitive "Maximum TX_CLK/RX_CLK/bus pin frequency", although it used to claim an absolute maximum speed for the data converters of 50MHz (probably at a price of increased noise.)
I bet it would get really hot, clocking the data converters at 50MHz each while having the low pass filter configured at 40MHz, and probably wildly out of spec RF.
That 50MHz figure was in the old datasheet dated 3/5/12, not the newer ones. I bet it would still work, though. One can dream.
-
- Posts: 303
- Joined: Mon Mar 04, 2013 4:53 pm
Re: Data transfer bandwidth?
Yes - the old datasheets say it can go faster. I'd highly recommend trying to clock it that fast and see what happens, but there are no guarantees other than I doubt you'll hurt the chip. As for the LPF, you can definitely bypass the LPF and go straight to the ADC if your signal is sufficiently band limited or you don't mind aliasing.
The FX3 interface runs at 100MHz at 32-bits wide and the FX3 is cool as a cucumber to the touch. The CMOS interface isn't the big power draw, but the PA's on the transmitter.
Could you potentially get 50MHz of bandwidth out of the part? Maybe? On a side note, the VCO can also tune lower (down to around 232.5MHz according to the table in the programming guide) but we are told the IC's only get tested down to 300MHz guaranteed.
In the end, dream big and try it all! We want to limit the official specs to what the IC vendors are willing to sign up for, but I fully encourage experimentation, reprogramming and pushing the limits!
The FX3 interface runs at 100MHz at 32-bits wide and the FX3 is cool as a cucumber to the touch. The CMOS interface isn't the big power draw, but the PA's on the transmitter.
Could you potentially get 50MHz of bandwidth out of the part? Maybe? On a side note, the VCO can also tune lower (down to around 232.5MHz according to the table in the programming guide) but we are told the IC's only get tested down to 300MHz guaranteed.
In the end, dream big and try it all! We want to limit the official specs to what the IC vendors are willing to sign up for, but I fully encourage experimentation, reprogramming and pushing the limits!
-
- Posts: 6
- Joined: Fri Mar 01, 2013 3:25 am
Re: Data transfer bandwidth?
It's not that I want to bypass the LPF, it's that I want to increase its cutoff frequency slightly (or maybe significantly if I can clock the data converters faster) - the TRX_LPF_CAL value can be used to adjust the actual LPF cutoff from -30% to +50% for a particular width setting.. If you set it for 28MHz (14MHz baseband) and then did +50%, you'd get a requirement for more than the sampling rate that the device is specified - aliasing galore.
This is the apparent TRX_LPF_CAL mapping, for anyone who's interested:
7 = 67%
6 = 80%
5 = 87%
4 = 100%
3 = 109%
2 = 120%
1 = 147%
0 = 153%
This is the apparent TRX_LPF_CAL mapping, for anyone who's interested:
7 = 67%
6 = 80%
5 = 87%
4 = 100%
3 = 109%
2 = 120%
1 = 147%
0 = 153%