Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

USRP2 support #18

Open
jnse opened this issue Aug 30, 2022 · 13 comments
Open

USRP2 support #18

jnse opened this issue Aug 30, 2022 · 13 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@jnse
Copy link

jnse commented Aug 30, 2022 •
edited
Loading

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.
@cpoore1
Copy link
Collaborator

cpoore1 commented Aug 31, 2022

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.

@cpoore1 cpoore1 added enhancement New feature or request help wanted Extra attention is needed labels Aug 31, 2022
@jnse
Copy link
Author

jnse commented Aug 31, 2022 •
edited
Loading

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
Copy link

rabarar commented Aug 31, 2022 via email

@cpoore1
Copy link
Collaborator

cpoore1 commented Sep 1, 2022

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
Copy link

rabarar commented Sep 1, 2022 via email

@jnse
Copy link
Author

jnse commented Sep 6, 2022

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
Copy link
Collaborator

cpoore1 commented Sep 17, 2022

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
Copy link
Author

jnse commented Sep 17, 2022 •
edited
Loading

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
Copy link
Author

jnse commented Mar 31, 2023

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

@cpoore1
Copy link
Collaborator

cpoore1 commented Apr 1, 2023

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
Copy link
Author

jnse commented Apr 1, 2023

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

@jnse
Copy link
Author

jnse commented Apr 2, 2023

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
Copy link
Collaborator

cpoore1 commented Apr 2, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jnse @rabarar @cpoore1