"Frequency" and "relative position of device center frequency" are modified after switching from RX to TX and back

[RaspCla]

Hello, I'm using version 6.3.0 / Windows 10 Pro, 64bit, version 10.0.19042 (most current verion). My hardware is a Hackrf one.

If I start receiving e.g. at 145.650 Mhz and are switching to TX (configured to 145.050Mhz) via simple PTT (or manually), the RX "frequency" and "relative position of device center frequency" have been changed from previous values. RX "frequency" is changed to 145.400 Mhz, "relative position of device center frequency" is changed to "Cen", independent if it was set to "Inf" odr "Sup" before. (sample rate is 1000 kS/s)

I'm using NFM modulator and demodulator, see picture attached Hope you can help

[f4exb]

Firstly I see you are using SoapySDR with HackRF. Why do you do that? HackRF has native support so you could use the HackRF plugin that by the way shows up in the list so you HackRF is recognized by the plugin.

Secondly you have to realize that HackRF is a half duplex device that has a single LO for Rx and Tx and therefore cannot use different Rx and Tx frequencies thus the last one (Rx or Tx) "wins". This is normal behavior.

[RaspCla]

If I use the native support (see attachment), I get a error message "Could not start sample source" as soon I start e.g. receiving. Sometimes even SDRangel is crashing immidiately after selecting HackRF as device.

In regard to half duplex device: I was aware of this fact but assumed that SDRangel will change the frequency while transmitting and change back after transmitting. That means I can not use HackRF e.g. for relais etc.

Thanks a lot for answering

[f4exb]

First point is covered with #718 but no luck so far... There is no assumption on a different frequency for Rx and Tx for any device. Some devices have independent Rx and Tx LOs (like LimeSDR) so this is essentially device dependent. However a more advanced version of PTT may implement this. I have this in mind but not elaborated enough yet to put it in a ticket.

[RaspCla]

Ok, would be great (new version of PTT). I just hade some additional issues, the "Relative position of device center frequency" is always at center (noise at waterfall), even if I select "Sup" or "Inf". But now I'm able to use 145,050Mhz for TX and 145.650Mhz for RX while using the PTT button. Even if I switch several times forth and back it works fine.

[RaspCla]

I did some additional investigations. If I use "Relative position of device center frequency" = "Cen" I can switch between both frequencies (RX <-> TX) and the frequency's are always swtiched to the defined values, correctly. If I set "Relative position of device center frequency" to "Sup" or "Inf" the RX frequency is modified while switching to TX. Additionally the "Relative position of device center frequency" is switched back to "Cen" I've the feeling the issue with wrong frequency is because the "Relative position of device center frequency" is not restored before returning from TX to RX. Just an idea. Is there a possibility to change this behavior?

Additionally I found out, that I can not set a "Relative position of device center frequency" <> "Cen" if the "Software decimation factor" = "1" (it works with "2", "4", "8")

[f4exb]

The "Relative position of device center frequency" affects how the transferred I/Q baseband from the device to the host is decimated (keeping the center part, taking the lower part, taking the upper part). If decimation is 1 (i.e. no decimation) this setting has of course no effect. Note that for decimations higher than 2 it will take some part of the upper or lower half according to a predefined fixed scheme. The purpose is to move away the center of reception from the DC of the device which is usually noisy even when DC correction is on.

[f4exb]

Questions answered. Handling frequency shifts in PTT is not planned or may be part of a new ticket.