USRP2 support - Githubissues

jnse commented 2 years ago

It would be nice if the USRP2 were to be supported out of the box.

There isn't really any technical reason the project shouldn't support the USRP2 as a device - even if some more of the uhd options were exposed to the end-user it would just work.

For instance, it would already help a great deal if i could simply set a device string like "addr=192.168.1.200,name,serial=2908,type=usrp2,uhd"

Moreover, I'm not sure why specifying the daughterboard is needed -it should be possible to probe the RX/TX capabilities from the device. There are many more daughterboards than the ones listed.

(in production boards) https://www.ettus.com/product-categories/rf-daughterboards/
(older boards) https://kb.ettus.com/Category:Legacy_Products

cpoore1 commented 2 years ago

Thanks for the hardware suggestion. I can add the USRP2 as an option pretty quickly if it works fine with the UHD blocks. The age and discontinued status are a little worrisome to me as I haven't tested one in a long time. I don't have one to test with now so I would have to takes someone's word on it and be provided with an example "uhd_find_devices" output.

I think I currently only use the daughterboard information to pull the frequency limits of a device to use in plotting/variable bounding. Although, I can imagine a time in the future when I will need what is listed in the probe output for setting other variable defaults instead of hard coding them in everywhere. I can add all the other daughterboards as well but I'll need to know the text in the "uhd_usrp_probe" output.

The device arguments are split across variables to make it easier to adjust. A generic UHD device could be done if all the required UHD block variables are capable of being jammed in one line but I don't know if that would be helpful or more confusing.

jnse commented 2 years ago

Hello!

Yes, the USRP2 works fine with the UHD blocks, and the device string i provided above works fine with gqrx. These are still used by many people because they are significantly cheaper on the second hand market than the in-production hardware a lot of times, and they are still very capable sdr's.

Attached is my uhd_find_devices and uhd_usrp_probe output.

For what it's worth, the standalone grc graphs seem to work fine with it, provided I give it the correct address (the serial seems optional) and change things like antenna names and maybe some other settings here and there.

The antenna and gain names vary, depending on which daughterboards are installed.

uhd_find_devices.txt

uhd_usrp_probe - USRP2 with XCVR2450 board uhd_usrp_probe - USRP2 with DBSRX2 board

I have an LFRX/LFTX board coming next week, I'll post the output of that one when I get it.

Another thing to keep in mind is that the rx/tx frequency ranges advertised by the boards do not necessarily equate the actual received frequency range if a local oscillator is used. (I often mix in a signal at the input to extend the RX range of my boards) - (this is something GQRX supports by setting a positive or negative LNB LO frequency to indicate stepping up or down by the given amount, which basically just adds/subtracts that offset from the frequencies displayed in the GUI - not that this is a big deal, it can be done in my head with math :) but it's something to keep in mind if you're hardcoding board ranges perhaps)

rabarar commented 2 years ago

I have a USRP N210 with a few daughterboards as well - as well as the GPSDO module - if you need more probe outputs let me know and I’ll share mine as well.

Is the BladeRF2.0 supported?

On Aug 31, 2022, at 12:03 PM, John Sennesael @.***> wrote:

Hello!

Yes, the USRP2 works fine with the UHD blocks, and the device string i provided above works fine with gqrx. These are still used by many people because they are significantly cheaper on the second hand market than the in-production hardware a lot of times, and they are still very capable sdr's.

Attached is my uhd_find_devices and uhd_usrp_probe output.

For what it's worth, the standalone grc graphs seem to work fine with it, provided I give it the correct address (the serial seems optional) and change things like antenna names and maybe some other settings here and there.

The antenna and gain names vary, depending on which daughterboards are installed. I have a few other daughterboards laying around to test with if you'd like the output for those as well.

uhd_find_devices.txt https://github.com/ainfosec/FISSURE/files/9463088/uhd_find_devices.txt uhd_usrp_probe.txt https://github.com/ainfosec/FISSURE/files/9463089/uhd_usrp_probe.txt — Reply to this email directly, view it on GitHub https://github.com/ainfosec/FISSURE/issues/18#issuecomment-1233132607, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABB2J6BKSXIMW5ENLQIJGFLV3566JANCNFSM6AAAAAAQAQ3QLY. You are receiving this because you are subscribed to this thread.

cpoore1 commented 2 years ago

Yes, thank you, I’ll gladly take those outputs. There is a BladeRF option but I was testing with one of the original versions. I have a BladeRF 2.0 micro and PlutoSDR on the way. Those I will test out, do the installs, and make options right away. Slowly, I’ll try to fill out all the flow graphs for the different types of hardware. I may have to rethink how some of them get saved and accessed so I don’t have so many similar copies.

rabarar commented 2 years ago

Here’s the probe for the USRP N210 with a WBX daughter board and GPSDO

% uhd_usrp_probe [INFO] [UHD] Mac OS; Clang version 13.1.6 (clang-1316.0.21.2.5); Boost_107900; UHD_4.2.0.HEAD-0-g321295fb [ERROR] [OCTOCLOCK] OctoClock network discovery error - send_to: No route to host [system:65] [ERROR] [OCTOCLOCK] OctoClock network discovery error - send_to: Host is down [system:64] [INFO] [USRP2] Opening a USRP2/N-Series device... [INFO] [USRP2] Current recv frame size: 1472 bytes [INFO] [USRP2] Current send frame size: 1472 bytes [INFO] [USRP2] Detecting internal GPSDO.... [INFO] [GPS] Found an internal GPSDO: Jackson-Labs, FireFly , Firmware Rev 0.929 [INFO] [USRP2] Setting references to the internal GPSDO [ERROR] [UHD] Device discovery error: send_to: Host is down [system:64] [ERROR] [USRP2] USRP2 Network discovery error send_to: Host is down [system:64] [ERROR] [USRP2] USRP2 Network discovery error send_to: Host is down [system:64] [ERROR] [X300] X300 Network discovery error send_to: Host is down [system:64] [ERROR] [X300] X300 Network discovery error send_to: Host is down [system:64] [ERROR] [OCTOCLOCK] OctoClock network discovery error - send_to: Host is down [system:64] [ERROR] [OCTOCLOCK] OctoClock network discovery error - send_to: Host is down [system:64]

Device: USRP2 / N-Series Device	_____	/
Time sources: none, external, external, mimo, gpsdo
Clock sources: internal, external, mimo, gpsdo
Sensors: gps_gpgga, gps_gprmc, gps_time, gps_locked, gps_servo, mimo_locked, ref_locked
_____
/
	RX DSP: 0

	Freq range: -50.000 to 50.000 MHz
_____
/
	RX DSP: 1

	Freq range: -50.000 to 50.000 MHz
_____
/
	RX Dboard: A
	ID: WBX v3, WBX v3 + Simple GDB (0x0057)
	Serial: F35E28
	_____
	/
		RX Frontend: 0
		Name: WBXv3 RX+GDB
		Antennas: TX/RX, RX2, CAL
		Sensors: lo_locked
		Freq range: 68.750 to 2200.000 MHz
		Gain range PGA0: 0.0 to 31.5 step 0.5 dB
		Bandwidth range: 40000000.0 to 40000000.0 step 0.0 Hz
		Connection Type: IQ
		Uses LO offset: No
	_____
	/
		RX Codec: A
		Name: ads62p44
		Gain range digital: 0.0 to 6.0 step 0.5 dB
		Gain range fine: 0.0 to 0.5 step 0.1 dB
_____
/
	TX DSP: 0

	Freq range: -200.000 to 200.000 MHz
_____
/
	TX Dboard: A
	ID: WBX v3 (0x0056)
	Serial: F35E28
	ID: WBX + Simple GDB, WBX v3 + Simple GDB, WBX v4 + Simple GDB, WBX-120 + Simple GDB (0x004f)
	Serial: 0
	_____
	/
		TX Frontend: 0
		Name: WBXv3 TX+GDB
		Antennas: TX/RX, CAL
		Sensors: lo_locked
		Freq range: 68.750 to 2200.000 MHz
		Gain range PGA0: 0.0 to 31.0 step 1.0 dB
		Bandwidth range: 40000000.0 to 40000000.0 step 0.0 Hz
		Connection Type: IQ
		Uses LO offset: No
	_____
	/
		TX Codec: A
		Name: ad9777
		Gain Elements: None

On Aug 31, 2022, at 11:00 PM, cpoore1 @.***> wrote:

Yes, thank you, I’ll gladly take those outputs. There is a BladeRF option but I was testing with one of the original versions. I have a BladeRF 2.0 micro and PlutoSDR on the way. Those I will test out, do the installs, and make options right away. Slowly, I’ll try to fill out all the flow graphs for the different types of hardware. I may have to rethink how some of them get saved and accessed so I don’t have so many similar copies.

— Reply to this email directly, view it on GitHub https://github.com/ainfosec/FISSURE/issues/18#issuecomment-1233676825, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABB2J6HPBYPNGWCIBO6O7VDV4AL5BANCNFSM6AAAAAAQAQ3QLY. You are receiving this because you commented.

jnse commented 1 year ago

Here's the USRP2 with an LFRX and an LFTX board installed.

  _____________________________________________________
 /
|       Device: USRP2 / N-Series Device
|     _____________________________________________________
|    /
|   |       Mboard: USRP2 r4
|   |   hardware: 1024
|   |   mac-addr: 00:50:c2:85:3b:5c
|   |   ip-addr: 192.168.1.200
|   |   subnet: 255.255.255.255
|   |   gateway: 255.255.255.255
|   |   gpsdo: none
|   |   serial: 2908
|   |   FW Version: 12.4
|   |   FPGA Version: 10.1
|   |   
|   |   Time sources:  none, external, _external_, mimo
|   |   Clock sources: internal, external, mimo
|   |   Sensors: mimo_locked, ref_locked
|   |     _____________________________________________________
|   |    /
|   |   |       RX DSP: 0
|   |   |   
|   |   |   Freq range: -50.000 to 50.000 MHz
|   |     _____________________________________________________
|   |    /
|   |   |       RX DSP: 1
|   |   |   
|   |   |   Freq range: -50.000 to 50.000 MHz
|   |     _____________________________________________________
|   |    /
|   |   |       RX Dboard: A
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       RX Frontend: 0
|   |   |   |   Name: Unknown (0xffff) - 0
|   |   |   |   Antennas: 
|   |   |   |   Sensors: 
|   |   |   |   Freq range: 0.000 to 0.000 MHz
|   |   |   |   Gain Elements: None
|   |   |   |   Bandwidth range: 0.0 to 0.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       RX Codec: A
|   |   |   |   Name: ltc2284
|   |   |   |   Gain Elements: None
|   |     _____________________________________________________
|   |    /
|   |   |       TX DSP: 0
|   |   |   
|   |   |   Freq range: -200.000 to 200.000 MHz
|   |     _____________________________________________________
|   |    /
|   |   |       TX Dboard: A
|   |   |   ID: LF TX (0x000e)
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       TX Frontend: AB
|   |   |   |   Name: LFTX (AB)
|   |   |   |   Antennas: 
|   |   |   |   Sensors: 
|   |   |   |   Freq range: -32.000 to 32.000 MHz
|   |   |   |   Gain Elements: None
|   |   |   |   Bandwidth range: 64000000.0 to 64000000.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       TX Frontend: BA
|   |   |   |   Name: LFTX (BA)
|   |   |   |   Antennas: 
|   |   |   |   Sensors: 
|   |   |   |   Freq range: -32.000 to 32.000 MHz
|   |   |   |   Gain Elements: None
|   |   |   |   Bandwidth range: 64000000.0 to 64000000.0 step 0.0 Hz
|   |   |   |   Connection Type: QI
|   |   |   |   Uses LO offset: No
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       TX Frontend: A
|   |   |   |   Name: LFTX (A)
|   |   |   |   Antennas: 
|   |   |   |   Sensors: 
|   |   |   |   Freq range: -32.000 to 32.000 MHz
|   |   |   |   Gain Elements: None
|   |   |   |   Bandwidth range: 32000000.0 to 32000000.0 step 0.0 Hz
|   |   |   |   Connection Type: I
|   |   |   |   Uses LO offset: No
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       TX Frontend: B
|   |   |   |   Name: LFTX (B)
|   |   |   |   Antennas: 
|   |   |   |   Sensors: 
|   |   |   |   Freq range: -32.000 to 32.000 MHz
|   |   |   |   Gain Elements: None
|   |   |   |   Bandwidth range: 32000000.0 to 32000000.0 step 0.0 Hz
|   |   |   |   Connection Type: Q
|   |   |   |   Uses LO offset: No
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       TX Codec: A
|   |   |   |   Name: ad9777
|   |   |   |   Gain Elements: None

cpoore1 commented 1 year ago

Is that what normally happens when probing with the LFRX? I might have to skip auto-detecting that one if other unrecognized boards do the same thing.

jnse commented 1 year ago

Yeah, the LFRX is a bit weird compared to other boards. It doesn't have a normal hardware way of tuning. It just sits at a center 0Hz frequency and gives you + and - the sample rate around it. It also does not have an adjustable gain.

jnse commented 1 year ago

@cpoore1 Do you still need anything from me (or other usrp2 users) in order to be able to implement this?

cpoore1 commented 1 year ago

Sure. I gave it my best shot at integrating it. I need to know if there are any errors with the hardware buttons detecting daughterboards or transferring those details to the UHD blocks in the flow graphs. So checking if the Guess and Probe buttons work and launching something like an Inspection flow graph in the IQ Data tab. Then maybe seeing if the sliders for gain and frequency don’t cause errors. If that all works I’d be more confident in copying all the attacks over and not worry so much about USRP2 complications for future updates.

jnse commented 1 year ago

Alright, I'll pull the latest and give it a try and report back :)

jnse commented 1 year ago

Guess & Probe

If I click 'Guess' the IP Address, serial, and daughterboard fields are correctly populated.
Clicking 'Probe' results in 'Please Wait' being shown for a little bit, which then goes away, but no fields are populated. Probe throws the following to stderr:

[ERROR] [UHD] Exception caught in safe-call.
  in ~usrp2_fifo_ctrl_impl
  at /var/tmp/portage/net-wireless/uhd-4.2.0.0/work/uhd-4.2.0.0/host/lib/usrp/usrp2/usrp2_fifo_ctrl.cpp:49
this->peek32(0); -> RuntimeError: fifo ctrl timed out looking for acks

The these errors are expected, as they also appear in the uhd_usrp_probe output - they can be safely ignored since it does still produce the correct output. I'm not sure if the probe button not doing much of anything is a result of FISSURE not ignoring the error or if something else is going on,... That said, with 'guess' working flawlessly, I don't think it's a big problem.

fissure_guess_probe

Inspection flow graph

Tested with waterfall_usrp2.py - everything seems to be working fine. The gain and frequency sliders seem to do what they are supposed to. Changing the sample rate via the drop-down works too (Although it'd be nice to be able to enter custom values - I can crank the usrp2 up to about 25 MS/s before the gigabit connection is saturated - it can in theory go higher if ethernet weren't the bottleneck - but whatever, good enough - it's easy enough to change the flowgraph if needed - not like anyone needs that crazy bw anyway - i digress... )

fissure_gain_slider

Conclusion

In the end it all seems to be working just fine for me. I did find that I had font rendering issues under my normal wm (fvwm3), which went away when I ran FISSURE under plasma - I'm not sure what's up with that - I'm guessing it's something to do with whatever default qt5 stylesheets end up being used - in fvwm3 I use stylesheets set by qt5ct but those aren't always picked up correctly by everything. - Anyway, none of that has anything to do with usrp2 usability, which is looking pretty good now!

cpoore1 commented 1 year ago

Good to know all that. I think the probe button is supposed to run uhd_usrp_probe with the ip address as an argument and print the output in a new window. I don't think anything is supposed to get populated from it. I must be doing something wrong with that command. It looks like there's a lot more to be done with those stylesheets. I'll check it out.

ainfosec / FISSURE

USRP2 support #18

Guess & Probe

Inspection flow graph

Conclusion