Re: [Discuss-gnuradio] USRP2-FLEX2400 Transmit and Receive problems
Hi, Thank you. Tx/Rx on the old Flex2400 using the usrp2 is now working. On 01/09/2010 21:41, Jason Abele wrote: On Wed, Sep 01, 2010 at 03:08:53PM -0400, Marcus D. Leech wrote: On 09/01/2010 12:51 PM, Jason Abele wrote: I'll need to do some re-soldering and burn-db-eeprom with USRP1 and hopefully this should fix the problem: http://gnuradio.org/redmine/wiki/1/USRPClockingNotes Also, since you use UHD, you can change the daughterboard ID of a daughterboard on a USRP2 from your host PC using: /share/uhd/utils/uhd_burn_db_eeprom An example of changing the DBID for a DBSRX is show here: http://www.ettus.com/uhd_docs/manual/html/dboards.html#id1 Jason So, Jason, is this because the older FLEX-series boards used an on-board clock that is *different* than the one supplied by the USRP2, and the driver code (either Classic or UHD) assumes a different clock rate than the one that was previously on-board, and thus is mis-programming the PLL? If the two clocks are the same frequency, then I don't understand why changing from "clock supplied on-board" to "clock supplied by USRP2" would "fix" the problem. Inquiring minds want to know... There are two problems: 1. When daughterboards were built with onboard oscillators, they were all 64MHz (presumably to play nicely with the USRP1 64MHz oscillator), but the USRP2 uses a 100MHz reference. Thus, when the daughterboard driver tunes the synthesizer, it is presuming a 100MHz reference on the USRP2 (actually, the UHD daughterboard drivers ask the motherboard what clock reference frequencies it can provide, and then chooses the "best" option), thus it would misconfigure the RFX synthesizer because it would not know that the reference frequency was 64MHz. 2. Actually, it never gets to mistuning the synthesizer because we used the daughterboard id to separate the "MIMO B" version of the RFX (ie. uses refclock from USRP motherboard) from the non-MIMO versions (with oscillator on board). However, the USRP2 (using either raw ethernet or UHD drivers) does not implement the daughterboard control for the non-MIMO versions. Hence why the burn_db_eeprom command is needed to change the daughterboard id. I put an issue in our issue tracker to add a warning to the UHD code and some notes in the daughterboard documentation to let users know about converting non-MIMO versions of the RFX to MIMO versions, I expect the fix will roll into one of the next few releases. Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2-FLEX2400 Transmit and Receive problems
On Wed, Sep 01, 2010 at 03:08:53PM -0400, Marcus D. Leech wrote: > On 09/01/2010 12:51 PM, Jason Abele wrote: > >>I'll need to do some re-soldering and burn-db-eeprom with USRP1 and > >>hopefully this > >>should fix the problem: > >>http://gnuradio.org/redmine/wiki/1/USRPClockingNotes > >Also, since you use UHD, you can change the daughterboard ID of a > >daughterboard on a USRP2 from your host PC using: > > > >/share/uhd/utils/uhd_burn_db_eeprom > > > >An example of changing the DBID for a DBSRX is show here: > >http://www.ettus.com/uhd_docs/manual/html/dboards.html#id1 > > > > > >Jason > > > > > So, Jason, is this because the older FLEX-series boards used an > on-board clock that is > *different* than the one supplied by the USRP2, and the driver code > (either Classic or > UHD) assumes a different clock rate than the one that was > previously on-board, and thus > is mis-programming the PLL? > > If the two clocks are the same frequency, then I don't understand why > changing from > "clock supplied on-board" to "clock supplied by USRP2" would "fix" > the problem. > Inquiring minds want to know... There are two problems: 1. When daughterboards were built with onboard oscillators, they were all 64MHz (presumably to play nicely with the USRP1 64MHz oscillator), but the USRP2 uses a 100MHz reference. Thus, when the daughterboard driver tunes the synthesizer, it is presuming a 100MHz reference on the USRP2 (actually, the UHD daughterboard drivers ask the motherboard what clock reference frequencies it can provide, and then chooses the "best" option), thus it would misconfigure the RFX synthesizer because it would not know that the reference frequency was 64MHz. 2. Actually, it never gets to mistuning the synthesizer because we used the daughterboard id to separate the "MIMO B" version of the RFX (ie. uses refclock from USRP motherboard) from the non-MIMO versions (with oscillator on board). However, the USRP2 (using either raw ethernet or UHD drivers) does not implement the daughterboard control for the non-MIMO versions. Hence why the burn_db_eeprom command is needed to change the daughterboard id. I put an issue in our issue tracker to add a warning to the UHD code and some notes in the daughterboard documentation to let users know about converting non-MIMO versions of the RFX to MIMO versions, I expect the fix will roll into one of the next few releases. Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2-FLEX2400 Transmit and Receive problems
On 09/01/2010 12:51 PM, Jason Abele wrote: I'll need to do some re-soldering and burn-db-eeprom with USRP1 and hopefully this should fix the problem: http://gnuradio.org/redmine/wiki/1/USRPClockingNotes Also, since you use UHD, you can change the daughterboard ID of a daughterboard on a USRP2 from your host PC using: /share/uhd/utils/uhd_burn_db_eeprom An example of changing the DBID for a DBSRX is show here: http://www.ettus.com/uhd_docs/manual/html/dboards.html#id1 Jason So, Jason, is this because the older FLEX-series boards used an on-board clock that is *different* than the one supplied by the USRP2, and the driver code (either Classic or UHD) assumes a different clock rate than the one that was previously on-board, and thus is mis-programming the PLL? If the two clocks are the same frequency, then I don't understand why changing from "clock supplied on-board" to "clock supplied by USRP2" would "fix" the problem. Inquiring minds want to know... -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2-FLEX2400 Transmit and Receive problems
> I'll need to do some re-soldering and burn-db-eeprom with USRP1 and hopefully > this > should fix the problem: > http://gnuradio.org/redmine/wiki/1/USRPClockingNotes Also, since you use UHD, you can change the daughterboard ID of a daughterboard on a USRP2 from your host PC using: /share/uhd/utils/uhd_burn_db_eeprom An example of changing the DBID for a DBSRX is show here: http://www.ettus.com/uhd_docs/manual/html/dboards.html#id1 Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2-FLEX2400 Transmit and Receive problems
You are using a very old RFX2400 which is configured with its own onboard oscillators instead of using the master oscillator from the motherboard. You can reconfigure it to work with USRP2 by following the directions under "Synchronizing all daughterboard LOs" here: http://gnuradio.org/redmine/wiki/1/USRPClockingNotes Matt On 08/31/2010 05:37 PM, Joseph Wamicha wrote: Hi, - I'm now using the uhd firmware and fpga code (txrx_uhd_20100706.bin and u2_rev3_uhd_20100706.bin images). - I get some interesting results; when running the examples, it appears that the daughterboard can not be recognized and is unknown. - I'm not sure if this in any way will affect the results but due to firmware/fpga incompatibilities between the host machine code and the firmware & fpga code (Error: Expected fpga compatibility number 1, but got 0:), I changed USRP2_FPGA_COMPAT_NUM and USRP2_FW_COMPAT_NUM to 0 and 5 from 1 and 6 in host/lib/usrp/usrp2/fw_common.h. I was then able to run the host/examples code. The code is straight out of the repository. Please find the results below: r...@astrodonius:git-uhd/host/examples# ./benchmark_rx_rate Creating the usrp device with: ... Target recv sock buff size: 5000 bytes Actual recv sock buff size: 131071 bytes Warning: The recv buffer is smaller than the requested size. The minimum recommended buffer size is 5000 bytes. See the USRP2 application notes on buffer resizing. Warning: unknown dboard-id or dboard-id combination: unknown (0x0007) -> defaulting to the unknown board type Warning: unknown dboard-id or dboard-id combination: unknown (0x000b) -> defaulting to the unknown board type RX samples per packet: 362 TX samples per packet: 363 Recv pirate num frames: 89 Using Device: Simple USRP: Device: usrp2 device Mboard: usrp2 mboard0 - rev 4:0 RX DSP: usrp2 ddc0 RX Dboard: usrp2 dboard (rx unit) RX Subdev: Unknown - unknown (0x0007) TX DSP: usrp2 duc0 TX Dboard: usrp2 dboard (tx unit) TX Subdev: Unknown - unknown (0x000b) OTesting receive rate 0.50 Msps (10.00 second run) Received packets: 13813 Received samples: 5000306 Lost samples: 0 Lost packets: 0 (approximate) Sustained receive rate: 0.50 Msps Testing receive rate 1.00 Msps (10.00 second run) Received packets: 27625 Received samples: 1250 Lost samples: 0 Lost packets: 0 (approximate) Sustained receive rate: 1.00 Msps Testing receive rate 2.00 Msps (10.00 second run) Received packets: 55249 Received samples: 2138 Lost samples: 0 Lost packets: 0 (approximate) Sustained receive rate: 2.00 Msps Testing receive rate 4.00 Msps (10.00 second run) Received packets: 110498 Received samples: 4276 Lost samples: 0 Lost packets: 0 (approximate) Sustained receive rate: 4.00 Msps Testing receive rate 8.33 Msps (10.00 second run) Received packets: 230203 Received samples: 8486 Lost samples: 0 Lost packets: 0 (approximate) Sustained receive rate: 8.33 Msps Testing receive rate 16.67 Msps (10.00 second run) Received packets: 460190 Received samples: 166588780 Lost samples: 78192 Lost packets: 216 (approximate) Sustained receive rate: 16.658847 Msps Testing receive rate 25.00 Msps (10.00 second run) ./lib/usrp/usrp2/fw_common.h Received packets: 683928 Received samples: 247581936 Lost samples: 2418160 Lost packets: 6680 (approximate) Sustained receive rate: 24.758184 Msps Done! r...@git-uhd/host/examples# ./rx_timed_samples Creating the usrp device with: ... Target recv sock buff size: 5000 bytes Actual recv sock buff size: 131071 bytes Warning: The recv buffer is smaller than the requested size. The minimum recommended buffer size is 5000 bytes. See the USRP2 application notes on buffer resizing. Warning: unknown dboard-id or dboard-id combination: unknown (0x0007) -> defaulting to the unknown board type Warning: unknown dboard-id or dboard-id combination: unknown (0x000b) -> defaulting to the unknown board type RX samples per packet: 362 TX samples per packet: 363 Recv pirate num frames: 89 Using Device: Simple USRP: Device: usrp2 device Mboard: usrp2 mboard0 - rev 4:0 RX DSP: usrp2 ddc0 RX Dboard: usrp2 dboard (rx unit) RX Subdev: Unknown - unknown (0x0007) TX DSP: usrp2 duc0 TX Dboard: usrp2 dboard (tx unit) TX Subdev: Unknown - unknown (0x000b) Setting RX Rate: 6.25 Msps... Actual RX Rate: 6.25 Msps... Setting device timestamp to 0... Begin streaming 1000 samples, 3 seconds in the future... OGot packet: 362 samples, 3 full secs, 0.00 frac secs Got packet: 362 samples, 3 full secs, 0.58 frac secs Got packet: 276 samples, 3 full secs, 0.000116 frac secs Done! r...@astrodonius:git-uhd/host/examples# ./tx_timed_samples Creating the usrp device with: ... Target recv sock buff size: 5000 bytes Actual recv sock buff size: 131071 bytes Warning: The recv buffer is smaller than the requested size. The minimum recommended buffer size is 5000 bytes. See the USRP2 application note
Re: [Discuss-gnuradio] USRP2-FLEX2400 Transmit and Receive problems
Hi Marcus, I get exactly the same behaviour. I have finally traced the problem to an old Flex2400 using an internal clock rather than the usrp2 clock. I'll need to do some re-soldering and burn-db-eeprom with USRP1 and hopefully this should fix the problem: http://gnuradio.org/redmine/wiki/1/USRPClockingNotes On 01/09/2010 03:20, Marcus D. Leech wrote: On 08/31/2010 01:48 PM, Joseph Wamicha wrote: Hi Leech, Thank you for your response. I'm using 2.4 GHz characterized antennas. No I'm not feeding the signal directly into the USRP2. I have a 2.4GHz resonant monopole antenna on the signal generator and another 2, 2.4GHz resonant antennas on both the RX and TX/RX SMA connectors of the FLEX2400. How close are the antennae? What parameters did you pass to usrp2_fft.py? If you look closely at the spectrum, it looks *perfectly* symmetrical about DC, which should never be the case if all the "pieces" agree that this is a complex signal. What happens if you tune usrp2_fft.py a few Khz away from 2.4GHz exactly? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2-FLEX2400 Transmit and Receive problems
On 08/31/2010 01:48 PM, Joseph Wamicha wrote: Hi Leech, Thank you for your response. I'm using 2.4 GHz characterized antennas. No I'm not feeding the signal directly into the USRP2. I have a 2.4GHz resonant monopole antenna on the signal generator and another 2, 2.4GHz resonant antennas on both the RX and TX/RX SMA connectors of the FLEX2400. How close are the antennae? What parameters did you pass to usrp2_fft.py? If you look closely at the spectrum, it looks *perfectly* symmetrical about DC, which should never be the case if all the "pieces" agree that this is a complex signal. What happens if you tune usrp2_fft.py a few Khz away from 2.4GHz exactly? -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2-FLEX2400 Transmit and Receive problems
The RFX2400 is dated 2/6/2006. On 01/09/2010 02:37, Joseph Wamicha wrote: Hi, - I'm now using the uhd firmware and fpga code (txrx_uhd_20100706.bin and u2_rev3_uhd_20100706.bin images). - I get some interesting results; when running the examples, it appears that the daughterboard can not be recognized and is unknown. - I'm not sure if this in any way will affect the results but due to firmware/fpga incompatibilities between the host machine code and the firmware & fpga code (Error: Expected fpga compatibility number 1, but got 0:), I changed USRP2_FPGA_COMPAT_NUM and USRP2_FW_COMPAT_NUM to 0 and 5 from 1 and 6 in host/lib/usrp/usrp2/fw_common.h. I was then able to run the host/examples code. The code is straight out of the repository. Please find the results below: r...@astrodonius:git-uhd/host/examples# ./benchmark_rx_rate Creating the usrp device with: ... Target recv sock buff size: 5000 bytes Actual recv sock buff size: 131071 bytes Warning: The recv buffer is smaller than the requested size. The minimum recommended buffer size is 5000 bytes. See the USRP2 application notes on buffer resizing. Warning: unknown dboard-id or dboard-id combination: unknown (0x0007) -> defaulting to the unknown board type Warning: unknown dboard-id or dboard-id combination: unknown (0x000b) -> defaulting to the unknown board type RX samples per packet: 362 TX samples per packet: 363 Recv pirate num frames: 89 Using Device: Simple USRP: Device: usrp2 device Mboard: usrp2 mboard0 - rev 4:0 RX DSP: usrp2 ddc0 RX Dboard: usrp2 dboard (rx unit) RX Subdev: Unknown - unknown (0x0007) TX DSP: usrp2 duc0 TX Dboard: usrp2 dboard (tx unit) TX Subdev: Unknown - unknown (0x000b) OTesting receive rate 0.50 Msps (10.00 second run) Received packets: 13813 Received samples: 5000306 Lost samples: 0 Lost packets: 0 (approximate) Sustained receive rate: 0.50 Msps Testing receive rate 1.00 Msps (10.00 second run) Received packets: 27625 Received samples: 1250 Lost samples: 0 Lost packets: 0 (approximate) Sustained receive rate: 1.00 Msps Testing receive rate 2.00 Msps (10.00 second run) Received packets: 55249 Received samples: 2138 Lost samples: 0 Lost packets: 0 (approximate) Sustained receive rate: 2.00 Msps Testing receive rate 4.00 Msps (10.00 second run) Received packets: 110498 Received samples: 4276 Lost samples: 0 Lost packets: 0 (approximate) Sustained receive rate: 4.00 Msps Testing receive rate 8.33 Msps (10.00 second run) Received packets: 230203 Received samples: 8486 Lost samples: 0 Lost packets: 0 (approximate) Sustained receive rate: 8.33 Msps Testing receive rate 16.67 Msps (10.00 second run) Received packets: 460190 Received samples: 166588780 Lost samples: 78192 Lost packets: 216 (approximate) Sustained receive rate: 16.658847 Msps Testing receive rate 25.00 Msps (10.00 second run) ./lib/usrp/usrp2/fw_common.h Received packets: 683928 Received samples: 247581936 Lost samples: 2418160 Lost packets: 6680 (approximate) Sustained receive rate: 24.758184 Msps Done! r...@git-uhd/host/examples# ./rx_timed_samples Creating the usrp device with: ... Target recv sock buff size: 5000 bytes Actual recv sock buff size: 131071 bytes Warning: The recv buffer is smaller than the requested size. The minimum recommended buffer size is 5000 bytes. See the USRP2 application notes on buffer resizing. Warning: unknown dboard-id or dboard-id combination: unknown (0x0007) -> defaulting to the unknown board type Warning: unknown dboard-id or dboard-id combination: unknown (0x000b) -> defaulting to the unknown board type RX samples per packet: 362 TX samples per packet: 363 Recv pirate num frames: 89 Using Device: Simple USRP: Device: usrp2 device Mboard: usrp2 mboard0 - rev 4:0 RX DSP: usrp2 ddc0 RX Dboard: usrp2 dboard (rx unit) RX Subdev: Unknown - unknown (0x0007) TX DSP: usrp2 duc0 TX Dboard: usrp2 dboard (tx unit) TX Subdev: Unknown - unknown (0x000b) Setting RX Rate: 6.25 Msps... Actual RX Rate: 6.25 Msps... Setting device timestamp to 0... Begin streaming 1000 samples, 3 seconds in the future... OGot packet: 362 samples, 3 full secs, 0.00 frac secs Got packet: 362 samples, 3 full secs, 0.58 frac secs Got packet: 276 samples, 3 full secs, 0.000116 frac secs Done! r...@astrodonius:git-uhd/host/examples# ./tx_timed_samples Creating the usrp device with: ... Target recv sock buff size: 5000 bytes Actual recv sock buff size: 131071 bytes Warning: The recv buffer is smaller than the requested size. The minimum recommended buffer size is 5000 bytes. See the USRP2 application notes on buffer resizing. Warning: unknown dboard-id or dboard-id combina
Re: [Discuss-gnuradio] USRP2-FLEX2400 Transmit and Receive problems
Hi, - I'm now using the uhd firmware and fpga code (txrx_uhd_20100706.bin and u2_rev3_uhd_20100706.bin images). - I get some interesting results; when running the examples, it appears that the daughterboard can not be recognized and is unknown. - I'm not sure if this in any way will affect the results but due to firmware/fpga incompatibilities between the host machine code and the firmware & fpga code (Error: Expected fpga compatibility number 1, but got 0:), I changed USRP2_FPGA_COMPAT_NUM and USRP2_FW_COMPAT_NUM to 0 and 5 from 1 and 6 in host/lib/usrp/usrp2/fw_common.h. I was then able to run the host/examples code. The code is straight out of the repository. Please find the results below: r...@astrodonius:git-uhd/host/examples# ./benchmark_rx_rate Creating the usrp device with: ... Target recv sock buff size: 5000 bytes Actual recv sock buff size: 131071 bytes Warning: The recv buffer is smaller than the requested size. The minimum recommended buffer size is 5000 bytes. See the USRP2 application notes on buffer resizing. Warning: unknown dboard-id or dboard-id combination: unknown (0x0007) -> defaulting to the unknown board type Warning: unknown dboard-id or dboard-id combination: unknown (0x000b) -> defaulting to the unknown board type RX samples per packet: 362 TX samples per packet: 363 Recv pirate num frames: 89 Using Device: Simple USRP: Device: usrp2 device Mboard: usrp2 mboard0 - rev 4:0 RX DSP: usrp2 ddc0 RX Dboard: usrp2 dboard (rx unit) RX Subdev: Unknown - unknown (0x0007) TX DSP: usrp2 duc0 TX Dboard: usrp2 dboard (tx unit) TX Subdev: Unknown - unknown (0x000b) OTesting receive rate 0.50 Msps (10.00 second run) Received packets: 13813 Received samples: 5000306 Lost samples: 0 Lost packets: 0 (approximate) Sustained receive rate: 0.50 Msps Testing receive rate 1.00 Msps (10.00 second run) Received packets: 27625 Received samples: 1250 Lost samples: 0 Lost packets: 0 (approximate) Sustained receive rate: 1.00 Msps Testing receive rate 2.00 Msps (10.00 second run) Received packets: 55249 Received samples: 2138 Lost samples: 0 Lost packets: 0 (approximate) Sustained receive rate: 2.00 Msps Testing receive rate 4.00 Msps (10.00 second run) Received packets: 110498 Received samples: 4276 Lost samples: 0 Lost packets: 0 (approximate) Sustained receive rate: 4.00 Msps Testing receive rate 8.33 Msps (10.00 second run) Received packets: 230203 Received samples: 8486 Lost samples: 0 Lost packets: 0 (approximate) Sustained receive rate: 8.33 Msps Testing receive rate 16.67 Msps (10.00 second run) Received packets: 460190 Received samples: 166588780 Lost samples: 78192 Lost packets: 216 (approximate) Sustained receive rate: 16.658847 Msps Testing receive rate 25.00 Msps (10.00 second run) ./lib/usrp/usrp2/fw_common.h Received packets: 683928 Received samples: 247581936 Lost samples: 2418160 Lost packets: 6680 (approximate) Sustained receive rate: 24.758184 Msps Done! r...@git-uhd/host/examples# ./rx_timed_samples Creating the usrp device with: ... Target recv sock buff size: 5000 bytes Actual recv sock buff size: 131071 bytes Warning: The recv buffer is smaller than the requested size. The minimum recommended buffer size is 5000 bytes. See the USRP2 application notes on buffer resizing. Warning: unknown dboard-id or dboard-id combination: unknown (0x0007) -> defaulting to the unknown board type Warning: unknown dboard-id or dboard-id combination: unknown (0x000b) -> defaulting to the unknown board type RX samples per packet: 362 TX samples per packet: 363 Recv pirate num frames: 89 Using Device: Simple USRP: Device: usrp2 device Mboard: usrp2 mboard0 - rev 4:0 RX DSP: usrp2 ddc0 RX Dboard: usrp2 dboard (rx unit) RX Subdev: Unknown - unknown (0x0007) TX DSP: usrp2 duc0 TX Dboard: usrp2 dboard (tx unit) TX Subdev: Unknown - unknown (0x000b) Setting RX Rate: 6.25 Msps... Actual RX Rate: 6.25 Msps... Setting device timestamp to 0... Begin streaming 1000 samples, 3 seconds in the future... OGot packet: 362 samples, 3 full secs, 0.00 frac secs Got packet: 362 samples, 3 full secs, 0.58 frac secs Got packet: 276 samples, 3 full secs, 0.000116 frac secs Done! r...@astrodonius:git-uhd/host/examples# ./tx_timed_samples Creating the usrp device with: ... Target recv sock buff size: 5000 bytes Actual recv sock buff size: 131071 bytes Warning: The recv buffer is smaller than the requested size. The minimum recommended buffer size is 5000 bytes. See the USRP2 application notes on buffer resizing. Warning: unknown dboard-id or dboard-id combination: unknown (0x0007) -> defaulting to the unknown board type Warning:
[Discuss-gnuradio] USRP2-FLEX2400 Transmit and Receive problems
Hi, We are currently experiencing Transmit and possibly Receive problems with the USRP2-Flex2400 boards. - The USRP2 is detected: # find_usrps -e eth0 00:50:c2:85:32:73 hw_rev = 0x0400 - The latest firmware and Raw Ethernet FPGA images have been written onto the SDRAM: u2_rev3-20100603.bin, u2_rev3-20100603.bin - To test receive, we transmit a 2.4GHz, 10 dBm RF signal using the HP 8350B Sweep Oscillator/Signal Generator. This is detected by both the USRP2-FLEX2400 (using usrp2_fft.py script) and Agilent Spectrum Analyzer. However, the usrp2_fft.py shows some odd sidebands around the the 2.4GHz central frequency when the signal generator is turned on. Also, there's barely any difference in dB receive strength with the signal generator turned on: > usrp2_fft.py output when signal generator is off: http://rrsg.ee.uct.ac.za/members/jwamicha/usrp2_fft-SignalGenerator-Off.png > usrp2_fft.py output when signal generator is off: http://rrsg.ee.uct.ac.za/members/jwamicha/usrp2_fft-SignalGenerator-On.png - Both LEDs D and F are lit up. - Gnuradio version 3.2.2 is being used on Ubuntu Lucid Lynx (10.04). We then turn off the Signal Generator, and transmit a 2.4GHz signal solely using the USRP2-FLEX2400 by running 'usrp2_siggen.py -f 2.4e9 -e eth0'. Nothing gets picked up by the Agilent Spectrum Analyzer USRP2-FLEX2400. Is there a USRP2-FLEX2400 transmit/receive problem while using the latest firmware and raw ethernet FPGA code? Could this be the symptoms of an SDRAM problem even if both LEDs D and F are lit up? Thanks, Jaw. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
