HackRF R0 and T1 frequencies locked together.

I need the ability to operate in split VFO mode to support WSJTX using HackRF device. WSJTX test the ability to do split operation at initilization and it this capability is not available it fails. In the case of HackRF I can not find a way to make the T1 frequency changes without effecting the R0 values. Am I missing something here?

In the case of Pluto the two do operate in split mode. I have compaired all the device and channel setting looking for a lock and do not see it.

I see a value for fcPos was added to the HackRF. This does allow the two to work independently but it causes some issues with adding frequency shift to the R0 value.

Can you fix the HackRF to allow split frequency and any other device that is currently locked?

If there is another solution please let me know.

Thanks, Bob N5BRG

In the case of HackRF I can not find a way to make the T1 frequency changes without effecting the R0 values. Am I missing something here?

Yes you are missing the fact that the HackRF uses the same LO for Rx and Tx. There is no way to circumvent this at least with a simple switchover from Tx to Rx or vice-versa. It means that you will have to maintain the different LO values on the "client" side.

The fcPos feature is there just to move the center of reception (or transmission) away from DC with a fixed value depending on the decimation factor. You need decimation first so this does not work for decimation = 1 i.e. no decimation.

As I understand your purpose is to make a Hamlib interface for SDRangel. Then what you need maybe is a dedicated feature plugin that maintains a state and does some "magic" for you on the server (SDRangel's) side. There s a similar plugin already for RigCtl: https://github.com/f4exb/sdrangel/tree/master/plugins/feature/rigctlserver

Thnaks for feedback.
I can not write the frequency on RxTX changes because I am already close to the time limit for WSJTX and this will add too much delay.

I may post my code and indicate HackRF is not supported due to this issue. Hamlib still useful for other applications like logging and I have tested with CQRLOG.

Your suggestion of the dedicated feature plugin may work if there is a way for SDRangel to support split mode frequency and turnaround TXRX fast. I would try that if you make it available or tell me where to look for for it.

When I add the RigCTL feature I can not make it start. I see the Enable Server option there as well. I did not understand you have a have a feature started before it will show up in the swagger GET. I have been looking for features at Index 0 but not seeing anthing until you mentioned it had to be running. Thanks.

I have the code doing a Preset of settings and put sample rate at about 4 MS/s and Decimation at 16 so I was seeing a higher frequency when fcPOS was set for 2 so this helped me understand how this worked. I realize now, fcPOS is not going to help me in this situation.

I do not have a LimeSDR. Does Lime have two LOs allowing split frequency in SDRangel? I may purchase on in the the current group buy offer if so to try the Lime for HF and add this rig to the Hamlib list. I have coded this as a dedicated section for SDRangel with rig number for each of the device types, 34001 (pluto) , 34002 (HackRF) , 34003 (RTL-SDR) ...

Bob N5BRG

Does Lime have two LOs allowing split frequency in SDRangel?

Yes the RF chip LMS7002M has separate Rx and Tx LOs. It also has NCOs (inside the TSP block) that allow different frequencies on RX1 and RX2 or TX1 and TX2. Look at "3. Block diagram" here: https://wiki.myriadrf.org/LimeMicro:LMS7002M_Datasheet. SDRangel gives control to Rx and Tx LOs independently as well as NCOs for individual channels.

I may purchase on in the the current group buy offer

I think you will not regret it. The LMS7002M chip is the most complete RF chip known to me so far. I don't think any other has both individual channel NCOs and FIRs in hardware.

Your suggestion of the dedicated feature plugin may work if there is a way for SDRangel to support split mode frequency and turnaround TXRX fast.

A feature plugin can do custom processing for your particular application. Anything that could be done manually can be orchestrated and a specific interface presented via the API. I still do not understand why Rx/Tx turnaround would be that slow. It cannot be any slower than if you were doing it manually. This sort of plugin could also take care of the intrinsic of each device support and make it more generic than having to specify which kind of device is connected (i.e. device type 34001, 34002, etc...)

I would try that if you make it available or tell me where to look for for it.

In order for me to put up something I need to know about the details of your requirements. So if you can post your code first this may help.

When I add the RigCTL feature I can not make it start.

That's odd or maybe there is a bug. Normally you would do this by POSTing to /sdrangel/featureset/{featureSetIndex}/feature/{featureIndex}/run

This is the log of a Rx to Tx switch of the same HackRF device using the Simple PTT feature triggered by the API:

log

``` 2021-04-22 10:35:21.819 (D) HttpConnectionHandler (0x55e29e79c700): received request from 192.168.0.3 (POST) /sdrangel/featureset/0/feature/1/actions 2021-04-22 10:35:21.819 (D) SimplePTT::handleMessage: MsgPTT: tx: true 2021-04-22 10:35:21.820 (D) SimplePTTWorker::handleMessage: MsgPTT 2021-04-22 10:35:21.820 (D) HackRFInput::handleMessage: MsgStartStop: stop 2021-04-22 10:35:21.820 (D) DSPDeviceSourceEngine::stopAcquistion 2021-04-22 10:35:21.820 (D) DSPDeviceSourceEngine::handleSynchronousMessages: DSPAcquisitionStop 2021-04-22 10:35:21.820 (D) DSPDeviceSourceEngine::gotoIdle 2021-04-22 10:35:21.820 (D) HackRFInput::stop 2021-04-22 10:35:21.820 (D) HackRFThread::stopWork 2021-04-22 10:35:21.855 (D) HackRFInputThread::run: stopped HackRF Rx 2021-04-22 10:35:21.855 (D) HackRFThread::stopWork 2021-04-22 10:35:21.855 (D) GLSpectrumGUI::handleInputMessages: message: SpectrumVis::MsgStartStop 2021-04-22 10:35:21.855 (D) NFMDemod::stop 2021-04-22 10:35:21.855 (D) DC offset:0.000000,0.000000 2021-04-22 10:35:21.855 (D) SimplePTTGUI::handleMessage: SimplePTT::MsgPTT 2021-04-22 10:35:21.855 (D) SimplePTTGUI::handleMessage: SimplePTTReport::MsgRadioState 2021-04-22 10:35:21.855 (D) HackRFGui::handleInputMessages: message: HackRFInput::MsgStartStop 2021-04-22 10:35:21.950 (D) HackRFOutput::handleMessage: MsgStartStop: start 2021-04-22 10:35:21.950 (D) DSPDeviceSinkEngine::initGeneration 2021-04-22 10:35:21.950 (D) DSPDeviceSinkEngine::handleSynchronousMessages: DSPGenerationInit 2021-04-22 10:35:21.950 (D) DSPDeviceSinkEngine::gotoIdle 2021-04-22 10:35:21.950 (D) DSPDeviceSinkEngine::gotoInit: m_deviceDescription: HackRFOutput sampleRate: 64000 centerFrequency: 433410000 2021-04-22 10:35:21.950 (D) DSPDeviceSinkEngine::gotoInit: initializing NFMMod 2021-04-22 10:35:21.950 (D) NFMMod::handleMessage: DSPSignalNotification 2021-04-22 10:35:21.950 (D) SpectrumVis::handleMessage: DSPSignalNotification: centerFrequency: 433410000 sampleRate: 64000 2021-04-22 10:35:21.950 (D) DSPDeviceSinkEngine::startGeneration 2021-04-22 10:35:21.950 (D) DSPDeviceSinkEngine::handleSynchronousMessages: DSPGenerationStart 2021-04-22 10:35:21.951 (D) DSPDeviceSinkEngine::gotoRunning 2021-04-22 10:35:21.951 (D) DSPDeviceSinkEngine::gotoRunning: HackRFOutput started 2021-04-22 10:35:21.951 (D) HackRFOutput::applySettings m_centerFrequency: 433410000 m_LOppmTenths: 0 m_bandwidth: 1750000 m_devSampleRate: 4096000 m_log2Interp: 6 m_fcPos: 2 m_biasT: false m_lnaExt: false m_vgaGain: 22 m_useReverseAPI: false m_reverseAPIAddress: "127.0.0.1" m_reverseAPIPort: 8888 m_reverseAPIDeviceIndex: 0 force: true 2021-04-22 10:35:21.952 (D) HackRFOutput::applySettings: sample rate set to 4096000 S/s 2021-04-22 10:35:21.952 (D) HackRFOutput: set interpolation to 64 2021-04-22 10:35:21.952 (D) DeviceHackRF::setDevicePPMCorrection: si5351c MSNA set to integer mode. 2021-04-22 10:35:21.952 (D) DeviceHackRF::setDevicePPMCorrection: si5351c MSNA rem 0 2021-04-22 10:35:21.952 (D) DeviceHackRF::setDevicePPMCorrection: si5351c MSNA xoppm 0 2021-04-22 10:35:21.952 (D) DeviceHackRF::setDevicePPMCorrection: si5351c MSNA xo 25000000 2021-04-22 10:35:21.952 (D) DeviceHackRF::setDevicePPMCorrection: si5351c MSNA a 32 2021-04-22 10:35:21.952 (D) DeviceHackRF::setDevicePPMCorrection: si5351c MSNA b 0 2021-04-22 10:35:21.952 (D) DeviceHackRF::setDevicePPMCorrection: si5351c MSNA c 1 2021-04-22 10:35:21.953 (D) DeviceHackRF::setDevicePPMCorrection: si5351c MSNA registers 26 <- 0 27 <- 1 28 <- 0 29 <- 14 30 <- 0 31 <- 0 32 <- 0 33 <- 0 2021-04-22 10:35:21.953 (D) DeviceHackRF::setDevicePPMCorrection: XTAL error adjusted by 0 PPM. 2021-04-22 10:35:21.953 (D) DeviceSampleStatic::calculateSinkDeviceCenterFrequency: desired center freq: 433410000 Hz device center freq: 433410000 Hz device sample rate: 4096000 S/s Actual sample rate: 64000 S/s center freq position code: 2 image frequency: 433410000 Hz 2021-04-22 10:35:21.953 (D) HackRFInput::setDeviceCenterFrequency: frequency set to 433410000 Hz 2021-04-22 10:35:21.953 (D) HackRFOutput:applySettings: TxVGA gain set to 22 2021-04-22 10:35:21.953 (D) HackRFInput:applySettings: Baseband BW filter set to 1750000 Hz 2021-04-22 10:35:21.954 (D) HackRFInput:applySettings: bias tee set to false 2021-04-22 10:35:21.954 (D) HackRFInput:applySettings: extra LNA set to false 2021-04-22 10:35:21.954 (D) HackRFInputThread::run: HackRF is not streaming 2021-04-22 10:35:21.954 (D) HackRFOutput::start: started 2021-04-22 10:35:21.954 (D) DSPDeviceSinkEngine::gotoRunning: starting NFMMod 2021-04-22 10:35:21.954 (D) NFMMod::start 2021-04-22 10:35:21.954 (D) DSPDeviceSinkEngine::gotoRunning: input message queue pending: 1 2021-04-22 10:35:21.954 (D) DSPDeviceSinkEngine::handleInputMessages: message: DSPSignalNotification 2021-04-22 10:35:21.954 (D) DSPDeviceSinkEngine::handleInputMessages: DSPSignalNotification: m_sampleRate: 64000 m_centerFrequency: 433410000 2021-04-22 10:35:21.954 (D) DSPDeviceSinkEngine::handleInputMessages: forward message to NFMMod 2021-04-22 10:35:21.954 (D) NFMMod::handleMessage: DSPSignalNotification 2021-04-22 10:35:21.954 (D) DSPDeviceSinkEngine::handleInputMessages: DSPSignalNotification: guiMessageQueue: 0x55e2900a40b0 2021-04-22 10:35:21.954 (D) NFMModBaseband::handleMessage: DSPSignalNotification: basebandSampleRate: 64000 2021-04-22 10:35:21.954 (D) UpChannelizer::createFilterChain: start: sig: [ -32000 : 32000 ] BW: 64000 chan: [ -9000 : 39000 ] rot: 16000 2021-04-22 10:35:21.954 (D) UpChannelizer::createFilterChain: complete: #stages: 0 BW: 64000 ofs: 15000 2021-04-22 10:35:21.954 (D) UpChannelizer::applyConfiguration: done: out: 64000 req: 48000 in: 64000 fc: 15000 2021-04-22 10:35:21.954 (D) NFMModSource::applyChannelSettings: channelSampleRate: 64000 channelFrequencyOffset: 15000 2021-04-22 10:35:21.954 (D) NFMModSource::applyAudioSampleRate: 48000 2021-04-22 10:35:21.954 (D) Interpolator::createPolyphaseLowPass: ntaps: 144 2021-04-22 10:35:21.954 (D) SimplePTTGUI::handleMessage: SimplePTTReport::MsgRadioState 2021-04-22 10:35:21.954 (D) HackRFOutputThread::run: started HackRF Tx 2021-04-22 10:35:21.954 (D) NCOF::setFreq: freq: 1000.000000 m_phaseIncrement: 85.333336 2021-04-22 10:35:21.954 (D) NCOF::setFreq: freq: 67.000000 m_phaseIncrement: 5.717333 2021-04-22 10:35:21.954 (D) HackRFOutputGui::handleInputMessages: message: DSPSignalNotification 2021-04-22 10:35:21.954 (D) HackRFOutputGui::handleInputMessages: DSPSignalNotification: SampleRate:64000, CenterFrequency:433410000 2021-04-22 10:35:21.954 (D) GLSpectrumGUI::handleInputMessages: message: SpectrumVis::MsgStartStop 2021-04-22 10:35:21.954 (D) GLSpectrumGUI::handleInputMessages: message: GLSpectrum::MsgReportSampleRate 2021-04-22 10:35:21.955 (D) HighPassFilterRC::configure: t: 5.76 a1: 0.159376 b0: 1.15938 2021-04-22 10:35:21.955 (D) NFMModSource::applyFeedbackAudioSampleRate: 48000 2021-04-22 10:35:21.955 (D) Interpolator::createPolyphaseLowPass: ntaps: 144 2021-04-22 10:35:21.955 (D) HackRFOutputGui::handleInputMessages: message: HackRFOutput::MsgStartStop 2021-04-22 10:35:21.955 (D) HackRFOutputGui::handleInputMessages: message: DSPSignalNotification 2021-04-22 10:35:21.955 (D) HackRFOutputGui::handleInputMessages: DSPSignalNotification: SampleRate:64000, CenterFrequency:433410000 2021-04-22 10:35:21.955 (D) GLSpectrumGUI::handleInputMessages: message: GLSpectrum::MsgReportSampleRate 2021-04-22 10:35:21.955 (D) DeviceSampleStatic::calculateSourceCenterFrequency: frequencyShiftScheme: 1 desired center freq: 433410000 Hz device center freq: 433410000 Hz device sample rate: 4096000 S/s Actual sample rate: 64000 S/s center freq position code: 2 2021-04-22 10:35:21.955 (D) HackRFInput::handleMessage: MsgSynchronizeFrequency: centerFrequency: 433410000 Hz 2021-04-22 10:35:21.955 (D) MainWindow::handleMessages: message: MainCore::MsgDeviceSetFocus 2021-04-22 10:35:21.955 (D) DSPDeviceSourceEngine::handleInputMessages: message: DSPSignalNotification 2021-04-22 10:35:21.955 (D) NFMModBaseband::handleMessage: DSPSignalNotification: basebandSampleRate: 64000 2021-04-22 10:35:21.955 (D) DSPDeviceSourceEngine::handleInputMessages: DSPSignalNotification: m_sampleRate: 64000 m_centerFrequency: 433410000 2021-04-22 10:35:21.955 (D) UpChannelizer::createFilterChain: start: sig: [ -32000 : 32000 ] BW: 64000 chan: [ -9000 : 39000 ] rot: 16000 2021-04-22 10:35:21.955 (D) DSPDeviceSourceEngine::handleInputMessages: forward message to SpectrumVis 2021-04-22 10:35:21.955 (D) UpChannelizer::createFilterChain: complete: #stages: 0 BW: 64000 ofs: 15000 2021-04-22 10:35:21.955 (D) SpectrumVis::handleMessage: DSPSignalNotification: centerFrequency: 433410000 sampleRate: 64000 2021-04-22 10:35:21.955 (D) UpChannelizer::applyConfiguration: done: out: 64000 req: 48000 in: 64000 fc: 15000 2021-04-22 10:35:21.955 (D) DSPDeviceSourceEngine::handleInputMessages: forward message to NFMDemod 2021-04-22 10:35:21.955 (D) NFMModSource::applyChannelSettings: channelSampleRate: 64000 channelFrequencyOffset: 15000 2021-04-22 10:35:21.955 (D) NFMModSource::applyAudioSampleRate: 48000 2021-04-22 10:35:21.955 (D) Interpolator::createPolyphaseLowPass: ntaps: 144 2021-04-22 10:35:21.955 (D) NFMDemod::handleMessage: DSPSignalNotification 2021-04-22 10:35:21.955 (D) DSPDeviceSourceEngine::handleInputMessages: DSPSignalNotification: guiMessageQueue: 0x55e294979ae8 2021-04-22 10:35:21.956 (D) NCOF::setFreq: freq: 1000.000000 m_phaseIncrement: 85.333336 2021-04-22 10:35:21.956 (D) NCOF::setFreq: freq: 67.000000 m_phaseIncrement: 5.717333 2021-04-22 10:35:21.956 (D) HighPassFilterRC::configure: t: 5.76 a1: 0.159376 b0: 1.15938 2021-04-22 10:35:21.956 (D) NFMModSource::applyFeedbackAudioSampleRate: 48000 2021-04-22 10:35:21.956 (D) Interpolator::createPolyphaseLowPass: ntaps: 144 2021-04-22 10:35:21.956 (D) NFMModBaseband::handleMessage: DSPSignalNotification: basebandSampleRate: 64000 2021-04-22 10:35:21.956 (D) UpChannelizer::createFilterChain: start: sig: [ -32000 : 32000 ] BW: 64000 chan: [ -9000 : 39000 ] rot: 16000 2021-04-22 10:35:21.956 (D) UpChannelizer::createFilterChain: complete: #stages: 0 BW: 64000 ofs: 15000 2021-04-22 10:35:21.956 (D) UpChannelizer::applyConfiguration: done: out: 64000 req: 48000 in: 64000 fc: 15000 2021-04-22 10:35:21.956 (D) NFMModSource::applyChannelSettings: channelSampleRate: 64000 channelFrequencyOffset: 15000 2021-04-22 10:35:21.956 (D) NFMModSource::applyAudioSampleRate: 48000 2021-04-22 10:35:21.956 (D) Interpolator::createPolyphaseLowPass: ntaps: 144 2021-04-22 10:35:21.956 (D) NCOF::setFreq: freq: 1000.000000 m_phaseIncrement: 85.333336 2021-04-22 10:35:21.956 (D) NCOF::setFreq: freq: 67.000000 m_phaseIncrement: 5.717333 2021-04-22 10:35:21.956 (D) HighPassFilterRC::configure: t: 5.76 a1: 0.159376 b0: 1.15938 2021-04-22 10:35:21.956 (D) NFMModSource::applyFeedbackAudioSampleRate: 48000 2021-04-22 10:35:21.956 (D) Interpolator::createPolyphaseLowPass: ntaps: 144 2021-04-22 10:35:21.992 (D) CWKeyer::handleMessage: MsgConfigureCWKeyer 2021-04-22 10:35:21.992 (D) CWKeyer::applySettings: m_dashKey: Qt::Key_Minus m_dashKeyModifiers: QFlags(NoModifier) m_dotKey: Qt::Key_Period m_dotKeyModifiers: QFlags(NoModifier) m_keyboardIambic: true m_loop: false m_mode: 0 m_sampleRate: 48000 m_text: "" m_wpm: 13 2021-04-22 10:35:21.992 (D) CWKeyer::handleMessage: MsgConfigureCWKeyer 2021-04-22 10:35:21.992 (D) CWKeyer::applySettings: m_dashKey: Qt::Key_Minus m_dashKeyModifiers: QFlags(NoModifier) m_dotKey: Qt::Key_Period m_dotKeyModifiers: QFlags(NoModifier) m_keyboardIambic: true m_loop: false m_mode: 0 m_sampleRate: 48000 m_text: "" m_wpm: 13 2021-04-22 10:35:21.992 (D) CWKeyer::handleMessage: MsgConfigureCWKeyer 2021-04-22 10:35:21.992 (D) CWKeyer::applySettings: m_dashKey: Qt::Key_Minus m_dashKeyModifiers: QFlags(NoModifier) m_dotKey: Qt::Key_Period m_dotKeyModifiers: QFlags(NoModifier) m_keyboardIambic: true m_loop: false m_mode: 0 m_sampleRate: 48000 m_text: "" m_wpm: 13 2021-04-22 10:35:21.992 (D) HackRFGui::handleInputMessages: message: HackRFInput::MsgConfigureHackRF 2021-04-22 10:35:21.993 (D) HackRFInputGui::updateFrequencyLimits: delta: 0 min: 0 max: 7250000 2021-04-22 10:35:21.993 (D) HackRFGui::handleInputMessages: message: DSPSignalNotification 2021-04-22 10:35:21.993 (D) HackRFGui::handleInputMessages: DSPSignalNotification: SampleRate:64000, CenterFrequency:433410000 2021-04-22 10:35:21.993 (D) GLSpectrumGUI::handleInputMessages: message: GLSpectrum::MsgReportSampleRate ```

The full turn around time is 174 ms.

I will work on posting my code to a Hamlib fork today.

My delay is WSJTX->Hamlib->my code module->REST->SDRangel->REST->my code module->Hamlib->WSJTX

Most of my code runs generic but each radio or device type has special needs. Hamlib has a trained user base that does not have to know how to use SDRangel to get started using SDRangel. Your RIGCTL feature will do a much better job if SDRangel takes on all the baggage of Hamlib.

There is a lot of work that goes on between WSJTX and Hamlib to make sure the different types of radios implement the protocol properly. I have been monitoring Hamlib and WSJTX development while this new JT65 mode is being tested and I was surprised to see how they are working with each rig. I was also told to get my module working with WSJTX as a hardness test. I now see how robust the interface has to be to keep working when WSJTX is running. Hamlib is not documented very well which also makes it difficult.

I added a PTT relay control in the mix too which effects timing a little.

My goal is to get WSJTX working on HF, VHF, UHF and Microwave using SDRangel and a few of the devices. I have started to test this.

Bob N5BRG

It looks to me like you support RIT and XIT in HackRF. So you must be updating the LO with the freq comprehending the RIT and XIT settings. The freq changes in WSJTX are small so I have been working to make it work by just using XIT. It means more IO to the REST though and may be a timing issue in faster WSJTX modes.

I did some testing with a couple of radios and unless i am fooling myself I see the different RIT and XIT values are allowing some split freq operation.

Also I believe another issue exist... I can write a new freq to centerFrequency which includes hz and the value is taken but the XIT or RIT hz are left at zero. SO I have to work in the blind for Hz stored in centerFrequency or round the centerFrequency value off and put the Hz in XIT/RIT.

Bob

I suppose that by RIT you mean RIT as on an analog radio on the receiving side and XIT the same on transmit side. There is no such thing directly supported in SDRangel. There are two things that may shift frequency however:

The transverter mode adds or removes any frequency shift from the center frequency setting before sending the command to the device. It is mostly useful for transverters in particular for QO-100 setups.
The modulators or demodulators can be placed anywhere in the baseband so they have a frequency offset that can be adjusted within the baseband. Be aware that performance of modulators in terms of out of band spurs may vary and generally are optimal at zero shift. However these spurs are generally acceptable.

Thank you for your comment. I understand and apreciate better the idea of centerFrequency. Yes, From my testing WSJTX does not move the freq much and it should still work. After checking to verify control I think WSJTX is adjusting freq to get best performance. Which covers a lot of issues.

I have managed to post my code at:

https://github.com/N5BRG/Hamlib.git

Most of my work is in rigs\sdrangel

This package will build on Ubuntu 20.04 and works with the SDRangel software and a Pluto, HackRF and RTLSDR.

The code has a dependency on the CURL library at https://curl.se/libcurl/. These functions are being used to do HTTP REST communication between my code and SDRangel when running. I was trying to stay in C because I was most comfortable and felt it would port to windows and Mac easier. With a good bit of effort I can try Python, using your examples, but I felt since it is an interperting language it would be slower.

My code still has sections commented out and other debug things in it for testing at this point.

I feel like my code is not good and I need to try using Python to do the interface with SDRangel. I am sending too much data back and forth and need to get it down to a minimum.

I think all my issues are understood and we can close this. Bob

f4exb / sdrangel

HackRF R0 and T1 frequencies locked together. #862