On 11/09/2015 19:11, Joe Taylor wrote: > Bill -- Hi Joe, > >> You may have this correct already but when setting a split Tx frequency >> the following sequence or an equivalent is necessary: >> >> if (m_monitoring || m_transmitting) { >> if (m_config.transceiver_online ()) { >> if (m_config.split_mode ()) { >> // All conditions are met, reset the transceiver dial frequency: >> Q_EMIT m_config.transceiver_tx_frequency (desired_frequency); >> } >> } >> } >> >> otherwise an attempt to set split when it has been disabled may occur. I >> assume that also means that you cannot enable the whole QSY from calling >> frequency to working frequency facility unless >> Configuration::split_mode() returns true. Of course "Fake" split mode is >> Ok too but again the user must have configured it. The above checks >> cover that. > Hmmm, then I'm not sure that I have this exactly right, yet. One issue > (probably not very important, but it slows down my testing with a > non-shack computer) is that if I require Configuration::split_mode() to > return true, I can't test using Rig=None, the default Hamlib radio. If > I leave out the > > if (m_config.split_mode ()) { > ... > } > > test, it works OK also with Rig=None. > > Does this make sense? Sort of, but obviously with Rig=None you cannot actually see if the QSY commands are working since the Rx frequency is the reported one. There's no problem doing this for testing but shouldn't be like that in production code since using Rig=None and split mode will never work.
This testing strategy may be the reason I see a lot of: ui->labDialFreq->setText (Radio::pretty_frequency_MHz_string (m_dialFreq)); in the code. I recently re-factored these so that the displayed frequency is that returned by the rig (applies to Rig-None too) rather than being set explicitly. I think we discussed this when the Doppler correction was being implemented and it was decided that the Tx frequency should be shown in that case but the dial frequency display seems to be decoupled from the actual rig frequency again. > > -- Joe 73 Bill G4WJS. ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel