开云体育

ctrl + shift + ? for shortcuts
© 2025 Groups.io

QMX+ back up clock accuracy


 

I'm using a QMX+ with the CR2032 installed and "QMX+ RTC" selected.

The problem is with the accuracy of the clock when the unit isn't switched on.

AFAICT, it's pretty accurate when the radio is operating in WSPR mode: it can run happily for several days at a time without any GPS input. However, if the unit's not powered up, the clock goes fast very quickly - I put the radio away for a few days and find the clock is several minutes fast, roughly 30 seconds a day. :-(

The 25MHz reference oscillator is virtually spot on: I've checked it using Hans's 20m WSPR tools (checked with both tx and rx), tweaked it a tiny bit (7Hz) and now everything's almost perfect.

Similarly, I've checked the CR2032's connections, cleaned the contacts and that seems well: the cell gives 3.15 volts measured at the PCB (healthy enough, surely?).

I find the on-screen time display helpful for logging purposes - I don't want to have to connect up the GPS or manually set it every time I leave the rig unused for a few days. What's up? How can I improve the accuracy?

73 Mark G?OIW


 

Hello Mark

Fixing the accuracy of the RTC is again something on my to-do list. The RTC runs from the 32.768 kHz crystal and like any uncompensated uncalibrated crystal they can be off. I will include some kind of software calibration to use the 25 MHz TCXO or GPS (if available) to fix this.?

Right now my priority is on SSB... I've got the SSB modulation working very well (see attached 700/1900 two tone test with excellent IMD3 performance) and now moving on to tackle the microphone audio processing, filtering and compression.?

But I will get to this RTC accuracy issue in due course. It's nothing wrong with your radio. So just wait a little please...

73 Hans G0UPL


On Sun, Sep 22, 2024, 14:07 Mark Palmer via <esperanto2023=outlook.com@groups.io> wrote:
I'm using a QMX+ with the CR2032 installed and "QMX+ RTC" selected.

The problem is with the accuracy of the clock when the unit isn't switched on.

AFAICT, it's pretty accurate when the radio is operating in WSPR mode: it can run happily for several days at a time without any GPS input. However, if the unit's not powered up, the clock goes fast very quickly - I put the radio away for a few days and find the clock is several minutes fast, roughly 30 seconds a day. :-(

The 25MHz reference oscillator is virtually spot on: I've checked it using Hans's 20m WSPR tools (checked with both tx and rx), tweaked it a tiny bit (7Hz) and now everything's almost perfect.

Similarly, I've checked the CR2032's connections, cleaned the contacts and that seems well: the cell gives 3.15 volts measured at the PCB (healthy enough, surely?).

I find the on-screen time display helpful for logging purposes - I don't want to have to connect up the GPS or manually set it every time I leave the rig unused for a few days. What's up? How can I improve the accuracy?

73 Mark G?OIW






Mike Black
 

Is there a CAT command to set the clock?

I have added QRPLabs? to Hamlib already so can customize it if there are extra commands available.

rigctl -l | find "QMX"
? 2052? QRPLabs? ? ? ? ? ? ? ? QCX/QDX/QMX? ? ? ? ? ? ?20240919.2? ? ? Stable? ? ? RIG_MODEL_QRPLABS

Mike W9MDB

On Sunday, September 22, 2024 at 06:37:39 AM CDT, Hans Summers <hans.summers@...> wrote:





Hello Mark

Fixing the accuracy of the RTC is again something on my to-do list. The RTC runs from the 32.768 kHz crystal and like any uncompensated uncalibrated crystal they can be off. I will include some kind of software calibration to use the 25 MHz TCXO or GPS (if available) to fix this.?

Right now my priority is on SSB... I've got the SSB modulation working very well (see attached 700/1900 two tone test with excellent IMD3 performance) and now moving on to tackle the microphone audio processing, filtering and compression.?

But I will get to this RTC accuracy issue in due course. It's nothing wrong with your radio. So just wait a little please...

73 Hans G0UPL



On Sun, Sep 22, 2024, 14:07 Mark Palmer via groups.io <esperanto2023@...> wrote:
I'm using a QMX+ with the CR2032 installed and "QMX+ RTC" selected.

The problem is with the accuracy of the clock when the unit isn't switched on.

AFAICT, it's pretty accurate when the radio is operating in WSPR mode: it can run happily for several days at a time without any GPS input. However, if the unit's not powered up, the clock goes fast very quickly - I put the radio away for a few days and find the clock is several minutes fast, roughly 30 seconds a day. :-(

The 25MHz reference oscillator is virtually spot on: I've checked it using Hans's 20m WSPR tools (checked with both tx and rx), tweaked it a tiny bit (7Hz) and now everything's almost perfect.

Similarly, I've checked the CR2032's connections, cleaned the contacts and that seems well: the cell gives 3.15 volts measured at the PCB (healthy enough, surely?).

I find the on-screen time display helpful for logging purposes - I don't want to have to connect up the GPS or manually set it every time I leave the rig unused for a few days. What's up? How can I improve the accuracy?

73 Mark G?OIW






 

Hi Mike?

Yes there's a CAT command "TM" for get/set of the real time clock. I forget the format but it should be documented in the operating manual along with all the other CAT commands.?

73 Hans G0UPL


On Sun, Sep 22, 2024, 15:01 Mike Black via <mdblack98=yahoo.com@groups.io> wrote:
Is there a CAT command to set the clock?

I have added QRPLabs? to Hamlib already so can customize it if there are extra commands available.

rigctl -l | find "QMX"
? 2052? QRPLabs? ? ? ? ? ? ? ? QCX/QDX/QMX? ? ? ? ? ? ?20240919.2? ? ? Stable? ? ? RIG_MODEL_QRPLABS

Mike W9MDB








On Sunday, September 22, 2024 at 06:37:39 AM CDT, Hans Summers <hans.summers@...> wrote:





Hello Mark

Fixing the accuracy of the RTC is again something on my to-do list. The RTC runs from the 32.768 kHz crystal and like any uncompensated uncalibrated crystal they can be off. I will include some kind of software calibration to use the 25 MHz TCXO or GPS (if available) to fix this.?

Right now my priority is on SSB... I've got the SSB modulation working very well (see attached 700/1900 two tone test with excellent IMD3 performance) and now moving on to tackle the microphone audio processing, filtering and compression.?

But I will get to this RTC accuracy issue in due course. It's nothing wrong with your radio. So just wait a little please...

73 Hans G0UPL



On Sun, Sep 22, 2024, 14:07 Mark Palmer via <esperanto2023=outlook.com@groups.io> wrote:
> I'm using a QMX+ with the CR2032 installed and "QMX+ RTC" selected.
>
> The problem is with the accuracy of the clock when the unit isn't switched on.
>
> AFAICT, it's pretty accurate when the radio is operating in WSPR mode: it can run happily for several days at a time without any GPS input. However, if the unit's not powered up, the clock goes fast very quickly - I put the radio away for a few days and find the clock is several minutes fast, roughly 30 seconds a day. :-(
>
> The 25MHz reference oscillator is virtually spot on: I've checked it using Hans's 20m WSPR tools (checked with both tx and rx), tweaked it a tiny bit (7Hz) and now everything's almost perfect.
>
> Similarly, I've checked the CR2032's connections, cleaned the contacts and that seems well: the cell gives 3.15 volts measured at the PCB (healthy enough, surely?).
>
> I find the on-screen time display helpful for logging purposes - I don't want to have to connect up the GPS or manually set it every time I leave the rig unused for a few days. What's up? How can I improve the accuracy?
>
> 73 Mark G?OIW
>
>
>
>
>
>









Mike Black
 

Tonight's build of Hamlib will have set_clock and get_clock for the QMX (does not work for QCX or QDX according to their manuals).
set_clock can take utc and local as arguments to set the current time.

rigctl -m 2052 -r com33 -vvv get_clock set_clock local get_clock
Opened rig model 2052, 'QCX/QDX/QMX'
0000-00-00T14:53:59.000+00:00
0000-00-00T09:54:00.000+00:00


rigctl -m 2052 -r com33 -vvv get_clock set_clock utc get_clock
Opened rig model 2052, 'QCX/QDX/QMX'
0000-00-00T09:54:06.000+00:00
0000-00-00T14:54:05.000+00:00

Mike W9MDB

On Sunday, September 22, 2024 at 09:02:03 AM CDT, Hans Summers <hans.summers@...> wrote:





Hi Mike?

Yes there's a CAT command "TM" for get/set of the real time clock. I forget the format but it should be documented in the operating manual along with all the other CAT commands.?

73 Hans G0UPL



On Sun, Sep 22, 2024, 15:01 Mike Black via groups.io <mdblack98@...> wrote:
Is there a CAT command to set the clock?

I have added QRPLabs? to Hamlib already so can customize it if there are extra commands available.

rigctl -l | find "QMX"
? 2052? QRPLabs? ? ? ? ? ? ? ? QCX/QDX/QMX? ? ? ? ? ? ?20240919.2? ? ? Stable? ? ? RIG_MODEL_QRPLABS

Mike W9MDB








On Sunday, September 22, 2024 at 06:37:39 AM CDT, Hans Summers <hans.summers@...> wrote:





Hello Mark

Fixing the accuracy of the RTC is again something on my to-do list. The RTC runs from the 32.768 kHz crystal and like any uncompensated uncalibrated crystal they can be off. I will include some kind of software calibration to use the 25 MHz TCXO or GPS (if available) to fix this.?

Right now my priority is on SSB... I've got the SSB modulation working very well (see attached 700/1900 two tone test with excellent IMD3 performance) and now moving on to tackle the microphone audio processing, filtering and compression.?

But I will get to this RTC accuracy issue in due course. It's nothing wrong with your radio. So just wait a little please...

73 Hans G0UPL



On Sun, Sep 22, 2024, 14:07 Mark Palmer via groups.io <esperanto2023@...> wrote:
I'm using a QMX+ with the CR2032 installed and "QMX+ RTC" selected.

The problem is with the accuracy of the clock when the unit isn't switched on.

AFAICT, it's pretty accurate when the radio is operating in WSPR mode: it can run happily for several days at a time without any GPS input. However, if the unit's not powered up, the clock goes fast very quickly - I put the radio away for a few days and find the clock is several minutes fast, roughly 30 seconds a day. :-(

The 25MHz reference oscillator is virtually spot on: I've checked it using Hans's 20m WSPR tools (checked with both tx and rx), tweaked it a tiny bit (7Hz) and now everything's almost perfect.

Similarly, I've checked the CR2032's connections, cleaned the contacts and that seems well: the cell gives 3.15 volts measured at the PCB (healthy enough, surely?).

I find the on-screen time display helpful for logging purposes - I don't want to have to connect up the GPS or manually set it every time I leave the rig unused for a few days. What's up? How can I improve the accuracy?

73 Mark G?OIW













 

Hans:? Brilliant work!? What tone frequencies are you using? The uneven IMs point to some AM->PM distortion.
Has any predistortion been applied?? Is there code space to do so?? Plans to do so???
?
73, Don N2VGU


 

Hello Don

700 / 1900 Hz, standard two tone frequencies. VFO on 7030 kHz (I know, CW segment nor SSB... It's only testing to the spectrum analyzer via 50 ohm attenuators).?

I'm using phase pre-distortion based on a measurement curve (not realtime feedback, which isn't available). See attached. Phase pre-distortion doesn't make much difference to IMD3 but does noticeably improve higher order intermodulation products.?

Amplitude modulation linearity is excellent and I cannot measure any distortion at all within the accuracy limitations of a simple measurement; except for the RF blowthrough from driver through the PA even when PA voltage is zero, which is about 1Vpp at the BNC antenna connector. I am able to zero that by switching off the driver completely but on/off is all the control I have over the driver (74ACT08). Switching off when the output should be below 1Vpp can be called amplitude pre-distortion of a sorr, and appears to make some improvement albeit small.?

It should be noted that the modulation method is quite different from a conventional SSB exciter and PA. A normal linear PA is most disturbed by the non-linearity distortion: a non-straight line of RF output vs RF input, caused normally by the inescapable fact that transistor characteristics are curves not straight lines, and straightening the situation out isn't easy. In the QMX PA the transistors are saturated on/off, there is no use of the transistors curvy characteristics at all. The amplitude modulation is at audio frequencies and the amplitude modulation circuit can be a lot more complex, in QMX it is made up of 4 transistors in a feedback arrangement driving a P-channel MOSFET. This is extremely linear. So the problems with a PA and SSB modulation using EER are quite different to conventional SSB and linear PAs.

In any case the QMX results so far compare very competitively with commercial black box transceivers with 20x the price tag. I reached the stage where as I tinker in ever more detail with DSP adjustments, I'm able to get a dB more of IMD3 at the expense of higher orders, or vice versa, small changes that are debatable which is more important. So it's time now to move on and connect up the microphone signals (digitally).

73 Hans G0UPL


On Sun, Sep 22, 2024, 18:59 Donald S Brant Jr via <dsbrantjr=gmail.com@groups.io> wrote:
Hans:? Brilliant work!? What tone frequencies are you using? The uneven IMs point to some AM->PM distortion.
Has any predistortion been applied?? Is there code space to do so?? Plans to do so???
?
73, Don N2VGU


 

Thanks for this! ?