Posts by impulse0879

  • Testing my new LibreSDR B220 (Ettus USRP B210 clone)

    Hello, I am back...


    I managed to find a solution for the RX overruns. Turns out you can tune the UHD rx/tx buffer size/count. So I wasn't too far off earlier. This solved the RX overflows at 61.44e6 for me on the first try, the only problem is you do need to recompile sdrangel to apply these "settings". Here's the patch file:

    ```

    --- a/devices/usrp/deviceusrpparam.cpp
    +++ b/devices/usrp/deviceusrpparam.cpp
    @@ -26,6 +26,7 @@ bool DeviceUSRPParams::open(const QString &deviceStr, bool channelNumOnly)
    try
    {
    std::string device_args(qPrintable(deviceStr));
    + device_args += ",num_recv_frames=512,num_send_frames=512";

    // For USB
    // The recv_frame_size must be a multiple of 8 bytes and not a multiple of 1024 bytes.
    ```


    Now even my little laptop can hit the full 61.44e6 sample rate without any overflows.


    For the record, this patch was simply based on the recommendations here - https://files.ettus.com/manual/page_us…00_known_issues

    (at the bottom of the page)


    Additionally, see this other page I found for more detailed bandwidth testing tools - https://www.sdrstore.eu/usrp-b210-troubleshooting-guide/

    (scroll to 'Problem: Overflow ('O') During Reception')


    Best regards

  • Testing my new LibreSDR B220 (Ettus USRP B210 clone)

    I was staring at the sdrangel logs today and I noticed that sometimes it wasn't actually taking the sample rate after I set it. I was setting it to the max by scrolling upwards on the first digit in the sample rate until it hit the max value of `61.444Msps`. Doing this produces the following log messages, indicating it's actually running at `32Msps`. Note that when this occurs the GUI will incorrectly show `61.444Msps`. At least this explains the glitches I've seen, where the signal clearly does not match the parameters that I've configured. I find the same issue sometimes occurs with the frequency setting (I can change it and.... nothing happens, still sitting there at the same frequency). I don't see the same issues in gnuradio, so this leads me to believe it's related to how sdrangel handles the configuration.

    Logs


    Additionally, after seeing the same overruns in GNURADIO I'm now less convinced that the following has anything to do with the problem at hand. I think it's either the transport layer or some buffer in libuhd.

    Quote from impulse0879

    Regarding performance issues

    While digging to see if they support `FASTLOCK MODE` I stumbled upon this code here.

    https://github.com/f4exb/sdrangel…pinput.cpp#L109

    I wonder if this is at all related to the performance issues discussed above? The comment suggests the current FIFO size was based on a max 50Msps, though these devices can actually go higher than that. Perhaps increasing the FIFO size would improve the performance for folks who are running into issues at the full sample rate.

  • Testing my new LibreSDR B220 (Ettus USRP B210 clone)

    Quote from VMA

    2) Depending on the tuned frequency, you will see many "birdies" - these go away if you just tune +/-1MHz - I find that annoying

    4) Spectrum sweeps are slow

    I have been doing some more research into these two points. The video here briefly touches upon both points.

    External Content youtu.be
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.


    Regarding number 2

    (Skip to timestamp 7:19)

    They discuss a filtering mechanism built into the AD9361. This may mitigate said "birdies" but it may not - I don't know.


    At first glance it looks like USRP supports this mechanism. They have a function to configure it... but I don't see them using it anywhere.

    https://github.com/EttusResearch/…evice.cpp#L2962


    I guess it is possible they aren't calling it simply because it is meant to be used by the end user (e.g. sdrangel). That would make sense, as there is probably not a sane default.


    Regarding number 4

    (Skip to timestamp 13:27)

    They discuss something called `FASTLOCK MODE`. I do not see support for this in the USRP code. If you are willing to do something more involved then you may find it suitable for your application. See the page here for more details/limitations.

    https://wiki.analog.com/resources/tool…s#fastlock_mode


    Note: Above that section they also discuss the use of the external clock input. Without a peek through the datasheet it's not clear to me if this would entirely replace the BBPLL (thus eliminating it's calibration/lock delay). But, assuming for a moment that it does replace the BBPLL and that you have an external clock source which can hop/lock faster than the internal BBPLL, this may also be suitable for your application.


    Regarding performance issues

    While digging to see if they support `FASTLOCK MODE` I stumbled upon this code here.

    https://github.com/f4exb/sdrangel…pinput.cpp#L109

    I wonder if this is at all related to the performance issues discussed above? The comment suggests the current FIFO size was based on a max 50Msps, though these devices can actually go higher than that. Perhaps increasing the FIFO size would improve the performance for folks who are running into issues at the full sample rate.

  • Testing my new LibreSDR B220 (Ettus USRP B210 clone)

    Quote from VMA

    but this is a problem because I use the PC for work and need it to be on Windows.

    I dual boot for the same reason, and I find it quite reliable these days. Back in the day there were many problems. Nowadays, so long as you have a second physical disk for the two images, it's quite stable. If you don't have two disks, Windows periodically erases your Linux EFI entry when it updates. Not that it is hard to fix that when it happens, but it is certainly... annoying :)

  • Testing my new LibreSDR B220 (Ettus USRP B210 clone)

    Quote from VMA

    Can you try SDRangel under Windows? I would be interested if you can demodulate FM radio with 61.444MS/s.

    Regards,
    Vitor


    I gave this a try today. I dual boot, so this is the exact same PC that was working at the full sampling rate in Linux. However, on Windows I cannot sample higher than 20MS/s before I get overruns:


    audio gets choppy if I go any higher than this. I would wager the USB (FX3 specifically, perhaps?) drivers are the culprit.

    Quote from VMA

    Which BFM pass filter did you toggle?

    I meant this selector that is built into the BFM plugin, inside the red box in the image here:

    BPF may be the wrong term... I have no real signal processing experience so I wasn't sure what else to call it :)


    On Linux, I can drag this "filter" back and forth across the entire spectrum (red arrows) and it would successfully demodulate any station I placed it over top of.


    Best regards

  • Testing my new LibreSDR B220 (Ettus USRP B210 clone)

    Hey folks,


    VMA, thanks for sharing some info on this radio. There's not much about it online! I wanted to share my experience with this radio as well. This is my first post here so I hope I'm not breaking any rules with links to stuff, etc :)


    To be specific, this is the b220 clone that I purchased: https://opensourcesdrlab.com/products/libresdr-b220-mini-ad9361

    It comes with the `7A200T` variant of the FPGA. I opted for this version for more room in the FPGA for experiments :).


    You noted above:

    Quote from VMA

    Conclusion: I don't see any different performance! Decoding BOM Cine (Hispasat) is only viable with 6MS/s. If you configure higher values, demodulation breaks. This is the same I got under Windows.

    The Linux PC is a Core i5-6300U with 16GB RAM. It is an industrial mini PC, so it is less performant than my main PC (Core i9-13900KF). I don't know how much this matters in terms of MS/s.

    With FM Broadcast it is the same: you can listen to radio up to 20MS/s on both (Linux/Windows). You can visualize up to 61.444MS/s, but here things start to break down. This is probably the limit of USB3.0.

    OTOH I've found that my radio can demodulate Broadcast FM in SDRAngel while sampling at the full 61.44MSPS. I can just slide the BFM pass filter around the whole range and it works. Note that this was with only one receive channel enabled. My PC specs are Ryzen 9 9900X / 32GB ram. So far I have only tested Linux, but I can test windows too if someone is curious.


    I will also note that I built the FPGA image from the source, it's in this repository here. https://github.com/bkerler/LibreSDR_UHD_B220_Mini_FPGA


    Personally I'm quite happy with the performance of this radio.