Basic pothos/other topology for TX under Windows

Hi,
For several months now, since I purchased LimeSDR Mini, I have been unsuccessful at transmitting.
The plan is simple - I have a I/Q stream from virtual soundcard (L = I, R = Q) which I simply need to "place" on the band.
Turns out that such task is so difficult that
nobody on MyriadRF responded
nobody on pothos-flow IRC and mailing list responded
nobody on rtl-sdr responded
and not even some members who might have an insight into this.

TX under windows is very limited for Lime platforms, the only "stable" way to do it is through PothosFlow or supplied GNURadio.
SDR Console v3 "promised" TX support for Mini in Dec 2017. No news.
SDRAngel doesn't work on Win for LimeSDR Mini as there's "issue with Zadiq installation".

I tried TX under Ubuntu, this time with real values not I/Q, namely using SDRAngel. It worked for analog audio, to some extent, but as it dropped samples like crazy, my COFDM stream was unreadable. This persisted on multiple PCs, hinting that CPU is not an issue there.

I realize this product is not meant to be substitution for any commercial grade transceiver, and that experimentation is a key here, but MAN if you're hitting the wall so hard from an early start, it gets demotivating quick.
Supposedly to operate SDR TCVR, you are expected to be proficient in DSP, filter design and electronics from the very start.

Can anybody please help me with this?
It would literary made my day to see the I/Q stream readable and on-the-air with no images, aliasing or distortion.

Hopefully this is the right place to ask this.
Thanks in advance!

I'd avoid windows at all costs, but that is simply my own bias.

Suggest you first write your I/Q "datastream" to a disk file. Then create a process to write the contents of that file to the SDR device. Assuming Linux and GNU Radio the file would end up cached in RAM after having been read one time. Then write a GNU radio flow graph consisting of two blocks (file source and SDR sink). In this way the creation of the file is separated from the writing of the file to the SDR. If you continue to get underruns then at least you'll have eliminated all of the steps that are possible to eliminate while still going through the motions of transmitting. At that point you would be left with a limited number of remaining variables, which are fairly straightforward to sort out....

I use a HackRF (Jawbreaker) for doing TX via the osmosdr sink. All works well, including using a non-trivial flowgraph to create several streams for simultaneous RF transmission...

73

Max

KA1RBI said:

I'd avoid windows at all costs, but that is simply my own bias.

Suggest you first write your I/Q "datastream" to a disk file. Then create a process to write the contents of that file to the SDR device. Assuming Linux and GNU Radio the file would end up cached in RAM after having been read one time. Then write a GNU radio flow graph consisting of two blocks (file source and SDR sink). In this way the creation of the file is separated from the writing of the file to the SDR. If you continue to get underruns then at least you'll have eliminated all of the steps that are possible to eliminate while still going through the motions of transmitting. At that point you would be left with a limited number of remaining variables, which are fairly straightforward to sort out....

I use a HackRF (Jawbreaker) for doing TX via the osmosdr sink. All works well, including using a non-trivial flowgraph to create several streams for simultaneous RF transmission...

73

Max

Click to expand...

I/Q datastream is generated on the fly, going offline shouldn't be necessary if I understand the process you described.
So "Soapy SDR Sink" block assumes 2ch input with Left channel as I and Right channel as Q?
If that's the case, then this flow should work:
Audio source > Converter (to Complex Float32) > Soapy SDR Sink

Is that correct?

andrew30 said:

this flow should work:
Audio source > Converter (to Complex Float32) > Soapy SDR Sink

Is that correct?

Click to expand...

No, it is not.

Max

KA1RBI said:

No, it is not.

Max

Click to expand...

OK, thanks for proving me wrong but..
I don't quite understand why should I bounce the stream into a file first, if I'm going to use it unchanged through File Source, wouldn't it do the same thing as using Audio Source?
As long as there aren't buffer underruns, it should work fine, no?
Converter to complex float_32 is necessary as Soapy SDR sink block only accepts stream in that format.

Is there a way to preserve "online nature" of the programme?

andrew30 said:

if I'm going to use it unchanged through File Source, wouldn't it do the same thing as using Audio Source?

Click to expand...

No it wouldn't. This is a classic example of the multiple clocks problem.

Max

Then a rational resampler?