Problem transmitting via second TX channel

Hi,

I wanted to test all TX and RX ports on my board in GNU Radio Companion and run into strange problem with using second TX channel. I want to transmit the same signal at different frequencies (shift by, say, 15 MHz or so) via TX1_1 and TX2_1 ports. As I read it here, I am supposed to set “Num Channels” to “2”. Also I have figured it out than you also need to add “nchan=2” to device arguments (it took me a while to find that information). Then I was actually able to run the flowgraph, but the problem is that it looks like both TX1_1 and TX2_1 ports are transmitting only signal prepared for TX2_1 at its frequency (moreover, shape of this signal transmitted via TX2_1 is kind of periodically attenuated in frequency domain).

I have also tried ‘UHD USRP Sink’ block (I have set “Num Channels” to “2” and “Stream chanels” to “[0,1]”), and again was able to run the flowgraph but it did not transmit anything at all.

Finally I have tried PothosGUI with all combinations of “Channels” and “Frontend Map” settings I could have think about, but with no luck.

So, has anyone succeeded with actually transmitting anything via TX2_1 port in those environments? Or, even better, transmit and receive by both channels at the same time (say: transmitting 10 MHz wide signal by TX1_1, receive it via RX1_L and, at the same time, transmitting the same 10 MHz wide signal by TX2_1 at frequency shifted by 15 MHz and receive it via RX2_L)?

@ccsh I tried using GNU radio and Pothos to create independent transmit channels but with no luck. I can transmit on channels A and B but only if they are on their own ie simplex. No duplex functionality except by using Limesuite.

1 Like

@TegwynTwmfatt,

…And what’s even stranger is that when I set something in LimeSuite that works, often those settings are latent and can be used in another application for a brief amount of time (until I make some major setting change, like frequency) and then it’ll revert back to not working - it’s like there’s a way for that condition to work, it’s just that the other apps aren’t implementing it the same way as LimeSuite does…Curious…What you may want to try is setting up the condition you want in GRC or Pothos, use LimeSuite the way you want to use it, and then restart GRC or Pothos using that condition to see if it will work - until some major change occurs. It’s happened that way for me in all my trials using LimeSuite and GQRX (at the time).

73 de Marty, KN0CK

@TegwynTwmfatt, can you describe how did you manage to use second channel in GnuRadio? I was not able to do even that (Osmocom Sink needs to use both channels or just the first one, it cannot use only second channel, and USRP Sink does not work in my case or I am doing something wrong…).

Sorry @ccsh but I can’t remember how I got channel b to work in gnu/pothos as I quickly moved on to lime suite instead. I would strongly recommend you do the same. There’s a couple of key settings in the limelight section for transmit that I can dig out if you need them.

Yes I noticed that a while back which enabled me to ‘harvest’ or ‘scoop’ lime suite settings out of pothos - well all except 2 or 3, which seemed to act like a kind of on/off switch for transmit.

1 Like

To be honest it would be quite dissapointing if you could use second channel only in LimeSuite (some applications may not allow that). I am going to try using second channel with SoapySDR API in a custom c++ application and report results here.

1 Like

Just for future reference: I have confirmed that you can use second channel both in SoapySDR and GNURadio Companion (with USRP Source/Sink blocks).

You just need to remember that both channels (in any direction, TX or RX) share the same LO, so the “RF frequency” will always be the same, and you can differentiate it only via “DSP frequency” offset, limited by device sampling rate. So the whole trick is to correctly form a tune request, so that only dsp_freq will be different for both channels, while rf_freq will still be the same.

2 Likes

I had to figure this out for the LTE repeater ini file. Don’t forget the filters.