Native Fobos SDR support in SDR Console

[UT2UM]

Dear Simon,

My name is Alex Antonov UT2UM. I am an engineer at RigExpert, Ukraine.

I would like to ask whether it would be possible to consider native support for our Fobos SDR receiver in SDR Console.

Fobos SDR is a wideband SDR receiver developed by Ukrainian engineers and manufactured in Ukraine by RigExpert. It covers a very wide frequency range and provides up to 50 MHz bandwidth over USB 3.0. More importantly, for us it is not only a hardware product, but also a project that we continue to actively support and improve.

Despite the very difficult situation in our country, we have not stopped production, we have not abandoned support, and we are continuing development. On the contrary, we are preparing new materials, updated libraries, firmware improvements, software examples, and, most importantly, a new improved version of the receiver.

For this reason, it would be a great honor for us if Fobos SDR could have native support in such respected and widely used software as SDR Console.

We already provide open-source API libraries, examples, and compatibility layers for different SDR applications. Here are the most relevant links:

Official Fobos SDR page:
https://rigexpert.com/software-defined- ... fobos-sdr/

Main Fobos SDR API library:
https://github.com/rigexpert/fobos-sdr

Classic libfobos API:
https://github.com/rigexpert/libfobos

SoapySDR plugin for Fobos SDR:
https://github.com/rigexpert/SoapyFobosSDR

Fobos SDR software/plugin update:
https://rigexpert.com/news/recent-updat ... fobos-sdr/

Enhanced Fobos SDR receiver / software support information:
https://rigexpert.com/news/rigexpert-is ... fobos-sdr/

From our side, we would be ready to help with the integration as much as possible. If you can provide detailed requirements, expected API/interface behavior, or a description of what is needed to implement a native SDR Console source module, we can prepare part of the work ourselves: API examples, test applications, documentation, Windows DLL packages, device control logic, sample-rate/bandwidth/gain tables, and remote or local testing.

We can also provide technical information about both currently used Fobos API branches, including the regular/classic API and the newer agile API, as well as describe the differences between firmware versions, streaming modes, RF/HF input selection, sample rates, bandwidth settings, LNA/VGA gain control, external clock support, and other hardware-specific parameters.

Our goal is not to create extra work for you without preparation. We would like to make the integration as convenient and well-documented as possible from our side.

SDR Console is one of the most respected SDR applications in the community, and native Fobos SDR support would be very valuable for our users. I believe it would also be useful for SDR Console users who are looking for a compact, wideband, USB 3.0 SDR receiver with active manufacturer support and open software libraries.

Please let us know whether this is something you would be willing to consider, and what would be the best technical path from your point of view.

Thank you very much for your work on SDR Console and for your time.

Best regards,
Alex Antonov, UT2UM
RF Engineer, RigExpert Ukraine
https://rigexpert.com/

[jdow]

I cannot speak for Simon. With a quick look at the GitHub code it looks like there is maybe enough there for him to work with. It might be good for the .h file or another file to be a little more descriptive of what ranges of input values and output values are accepted, legal, and returned from the API calls. I suspect it would also be useful if you were to negotiate with Simon to send him a sample or a loaner. That would speed up development. At the moment, though, I don't think he is anxious to add new radios. He has a long list of user wants to play with. Although, maybe a radio or two to hook up would be a nice "break" from the want lists. The whole "SDR-Radio (V3)" software suite has been written by Simon alone. So he does not have helpers to do any of the work. (Nor does he accept much if any help.)

{^_^} I'll see if I can point him here.

[UT2UM]

I cannot speak for Simon. With a quick look at the GitHub code it looks like there is maybe enough there for him to work with. It might be good for the .h file or another file to be a little more descriptive of what ranges of input values and output values are accepted, legal, and returned from the API calls. I suspect it would also be useful if you were to negotiate with Simon to send him a sample or a loaner. That would speed up development. At the moment, though, I don't think he is anxious to add new radios. He has a long list of user wants to play with. Although, maybe a radio or two to hook up would be a nice "break" from the want lists. The whole "SDR-Radio (V3)" software suite has been written by Simon alone. So he does not have helpers to do any of the work. (Nor does he accept much if any help.)

{^_^} I'll see if I can point him here.

Thank you very much for your reply and for taking a look at the available code.

Yes, I fully understand how difficult it must be to maintain and develop such a large and complex software project mostly alone. I definitely do not want to create extra work for Simon without proper preparation from our side.

Your point about the API documentation is very helpful. We can prepare a more complete and practical integration package, including:

- a clear description of the API calls;
- valid input ranges and returned values;
- supported sample rates, bandwidth settings, gain ranges, input modes, GPO control, external clock options, etc.;
- a short firmware/API compatibility table;
- a minimal Windows x64 DLL package;
- simple C/C++ examples for device opening, configuration, streaming, and closing;
- notes about the regular/classic API and the newer agile API, with a recommended primary integration path.

Our goal would be to make the first step as easy as possible: not just “here is a GitHub repository”, but a compact and well-documented package specifically prepared for SDR Console integration.

Regarding the hardware sample: yes, this is absolutely possible. In fact, we already have a Fobos SDR unit packed and ready to be sent. We only need the correct postal address and preferred shipping details. Of course, this can be arranged privately by email or private message if Simon is interested.

Thank you also for offering to point Simon to this topic. We would be very grateful if he could take a look when he has time. There is no pressure from our side — we fully understand that he has many priorities and user requests. We simply want to make it clear that RigExpert is ready to support the integration as much as possible, both technically and with hardware for testing.

Best regards, Alex

[Simon G4ELI]

Hi Alex,

I have looked at the Github files but I do not see information about the returned data, it is IQ, ADC samples or ? Can you show me a file which receives the samples and generates the IQ?

Fobos is not in stock in England!

[UT2UM]

Hi Alex,

I have looked at the Github files but I do not see information about the returned data, it is IQ, ADC samples or ? Can you show me a file which receives the samples and generates the IQ?

Fobos is not in stock in England!

Hi Simon,

Thank you very much for looking at the files.

First of all, sorry if my replies here are not very fast. My messages on the forum seem to go through moderation, so there may be some delay before they appear. If it is more convenient for discussing technical details, I would be happy to continue the engineering part by e-mail.

Yes, I agree — the current GitHub documentation does not explain the returned sample format clearly enough. I will ask our developer to improve this in the README/header comments.

In normal receive mode Fobos returns complex baseband IQ samples, not raw ADC samples.

The sample stream returned by the API is 32-bit floating point IQ data, interleaved as:

I0, Q0, I1, Q1, I2, Q2, ...

So the host application receives ready-to-use complex IQ samples for SDR processing.

The most relevant files are:

Classic / regular API:
https://github.com/rigexpert/libfobos/b ... os/fobos.h

Basic example / recorder:
https://github.com/rigexpert/fobos-sdr/ ... n/recorder

Agile API:
https://github.com/rigexpert/libfobos-s ... obos_sdr.h

Agile recorder example:
https://github.com/rigexpert/libfobos-s ... /main/eval

In the classic API the async streaming function is:

fobos_rx_read_async(...)

with callback:

typedef void(*fobos_rx_cb_t)(float *buf, uint32_t buf_length, void *ctx);

There is also synchronous reading:

fobos_rx_start_sync(...)
fobos_rx_read_sync(...)
fobos_rx_stop_sync(...)

In the Agile API the idea is similar:

fobos_sdr_read_async(...)

with callback:

typedef void(*fobos_sdr_cb_t)(float buf, uint32_t buf_length, struct fobos_sdr_dev_t sender, void *user);

The Agile API also has synchronous reading:

fobos_sdr_start_sync(...)
fobos_sdr_read_sync(...)
fobos_sdr_stop_sync(...)

Fobos currently has two API branches:

Classic / regular API
Used with the standard firmware. This is the straightforward API for normal receiver operation.
Agile API
Used with the newer agile firmware. This branch was created for faster tuning and scanning scenarios. The agile firmware/API can provide scanning speed up to about 14 GHz/s, which is important for fast spectrum search, monitoring and panoramic applications. This is the main reason why we have a second API branch and not only the classic one.

For a first SDR Console implementation, the normal receiver use case can remain simple: enumerate device, open, set frequency, set sample rate, set bandwidth if using Agile API, set LNA/VGA gain, then start IQ streaming.

Later, if SDR Console could benefit from faster search or scanning functions, the Agile API would be the more interesting branch to look at.

Regarding hardware availability in England: this should not be a problem. If a physical unit is needed for development and testing, we can arrange shipment either directly from Ukraine or from one of our European partners. Our logistics team should be able to handle this quickly.

I can also prepare a small minimal C/C++ example specifically for you, which only opens Fobos, sets frequency/sample rate/gain, receives IQ samples and writes them to a simple raw IQ file.

Best regards,
Alex Antonov, UT2UM
RF Engineer, RigExpert Ukraine