On 17/03/2015 15:56, Michael Black wrote: Hi Mike, > Makes sense...I was testing with "None" for the rig selection. > It ends up defaulting to "1.838" in the band selection and a freq of 14.078 > on every startup so I was expecting to see 14.078 on m_dialFreq. > The 14.078 is the default value in mainwindow.ui -- can't find there the > 1.838 gets set. I see it in Configuration.cpp. Even with Rig set to "None" you have rig control features. You have probably set the band to 160m at some point and that has been stored in the settings as the last monitored band. I believe the dummy Hamlib back end that Rig "None" uses defaults to 2m. If you change the band in WSJT-X and turn on "Monitor" the new frequency will be stored. > > Mike W9MDB 73 Bill G4WJS. > > > -----Original Message----- > From: Bill Somerville [mailto:[email protected]] > Sent: Tuesday, March 17, 2015 10:34 AM > To: [email protected] > Subject: Re: [wsjt-devel] UDP Server > > On 17/03/2015 15:14, Michael Black wrote: > Hi Mike, >> I'll keep it simple and just send the band to the client. JTAlert can >> use it for all the alert checking. >> >> I stuck this in: >> QString band = m_config.bands ()->data (m_config.bands ()->find >> (m_dialFreq)).toString(); >> >> But I see m_dialFreq is initialized to zero and, at least for my >> testing on playing back recorded signals, m_dialFreq does not get >> updated until the 2nd playback file. > m_dialFreq is mirroring the rig dial frequency, it may take a while to get > updated since the rig control is asynchronous and the signal from the rig > control thread only arrives after the first successful poll of the rig. >> So I get OOB on the first decode. Looks like it's OK on real-time >> decoding though. >> Perhaps m_dialFreq should get initialized to what the screen says? > It is the other way around. The UI widget is initialized with a default > value but that gets replaced on the first update from the rig. >> Mike W9MDB > 73 > Bill > G4WJS. >> >> >> >> -----Original Message----- >> From: Bill Somerville [mailto:[email protected]] >> Sent: Tuesday, March 17, 2015 9:15 AM >> To: WSJT software development >> Subject: Re: [wsjt-devel] UDP Server >> >> On 17/03/2015 13:21, Michael Black wrote: >> Hi Mike, >>> Question on determining band. I'd like to send the desired CQ band >>> info to WSJT-X which means WSJT-X has to tell the client what band >>> was >> decoded. >>> PAOTBR sent a patch in to add band to the separator that hasn't been >>> integrated yet: >>> >>> QString band = ADIF::bandFromFrequency ((m_dialFreq + >>> ui->TxFreqSpinBox->value ()) / 1.e6); >>> >>> But....is the decoded band obvious? Will it be the band that was >>> active at the 48 or 50 second mark? I don't see where this info is >>> retained. The user could obviously change the band at any time but I >>> think the 48 second mark is where it's most accurate...correct? Not >>> the >> 50 second mark? >> Related to this, what is WSJT-X going to do with this band? Remember >> that the band to frequency relationship is one to many and therefore >> band is only really of value for display purposes, you can't take any >> definitive action based on the band alone. >>> Mike W9MDB >> 73 >> Bill >> G4WJS.
------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
