Correction value is out of range

Placement, modules, components and accessories; the ones that exist and the the nice-to-be's
John Loftus
Posts: 6
Joined: Fri Mar 04, 2022 12:49 pm

Correction value is out of range

Post by John Loftus » Mon Mar 14, 2022 12:28 am

Hi,

For the most part, my three Red Pitayas (RP)s are working fine as WSPR transceivers using Pavel Demin's excellent work.

I have recently installed three gps pps modules - one to each of my three to STEMlab 122.88-16 SDR for WSPR Transceiver applications - intended for frequency accuracy and minimum drift.

I'm looking for a solution to a problem where the "update-corr.log" reports "Correction value is out of range" (CVOR). These reports present in clusters with a typical pattern of 2 to 4 CVOR reports at intervals of about 50 minutes apart. At other times the patterns have appeared as a cluster of about 15 consecutive CVOR reports at about 5 hours apart.

All three of my RPs have the same problem. The CVOR reports are not synchronised between each of the three RPs

The annoying part of the problem is that spot uploads are missed at the same time as CVOR appears in the log.

Things that I have already tried include:
(a) supplying the 3.3V GPS module from a clean regulated source - independent of the RP voltage supply.

(b) adjusting the corr value over a wide range. The ideal corr setting is currently set at -0.07. At this setting, my WSPR frequency reports are within 1 Hz of top operator Rob AI6VN/KH6

(c) using an external active gps antenna, located with full view of sky.

(d) confirming that the chronyc sources have adopted the pps source.

(e) I have looked at chronyc tracking (but the tracking reports are outside my scope of understanding).

The gps module is a "Duinotech GPS receiver with On-Board antenna" based on NEO-7M. The module also has an SMA connector for external antenna. I use this SMA connector with external antenna.

Any ideas how to solve this puzzle will much appreciated.

Regards,
John VK4EMM / VK4CT

pavel
Posts: 786
Joined: Sat May 23, 2015 5:22 pm

Re: Correction value is out of range

Post by pavel » Wed Mar 16, 2022 3:34 pm

Thank you for the testing of the frequency correction.

I have just checked the related code and I do not see how the problem with the frequency measurement could affect the spot uploads. When the error appears, the configuration files are not modified and the previously measured correction value is used.

This may be an indication that something is wrong with the FPGA configuration and that the frequency measurement and the SDR stop working at the same time. I will have to reproduce this problem and try to figure out what is triggering it. For now, I would say that something that affects both the frequency measurement and the SDR is the ADC clock. So maybe the problem is with the ADC shutting down from time to time. Maybe it is overheating. Do you have a cooling fan on your Red Pitaya boards?

When I connected a GPS module to the Red Pitaya board, I also used a separate power supply and an external GPS antenna. However, the GPS module I used refused to work when its ground was connected to the ground of the Red Pitaya board. I had to isolate the GPS module from the Red Pitaya board using ISO7741EVM.

John Loftus
Posts: 6
Joined: Fri Mar 04, 2022 12:49 pm

Re: Correction value is out of range

Post by John Loftus » Thu Mar 17, 2022 5:20 am

Hello Pavel,

Thank you for looking into my CVOR concerns.

With all of the 16 channels working hard, I recognised need for good cooling from the beginning.

Cooling is implemented at three levels:
1) housed in the genuine Red Pitaya aluminium case;
2) added aluminium heat sink to top of aluminium case.
2) fan forced air beneath the slots at bottom of aluminium case;
The forced air also flows around the aluminium case.

The installation room does get warm during the day - up to 35 degrees C.

On 27 Feb 2022, I noticed one RP (RP#3) missed spot uploads in the period from 06:54 UTC to 07:28 UTC. During that period, missed uploads coincided with alignment of records in decode-wspr.log and update-corr.log. I can send you a copy of the logs if you wish (small file sizes).

I have not yet reproduced the missing uploads aspect since 27 Feb 2022.

The same CVOR messages appear on all three RPs.
Erwin has reproduced the same error messages in his update-corr.log - in clusters of 9 to 10.

I understand that the configuration files are not modified and the previously measured correction value is used. However, I do not understand the process of error correction in the RP.

I'm pleased that you are looking into the reason why the CVOR message is raised - particularly in a pattern of clusters regularly through the day? As I say, all 16 channels are certainly working hard through every of every day.

I look forward to learning more about your findings.

Again, thank you for your excellent work with SDR on Red Pitaya.

Regards,
John VK4EMM / VK4CT

pavel
Posts: 786
Joined: Sat May 23, 2015 5:22 pm

Re: Correction value is out of range

Post by pavel » Thu Mar 17, 2022 8:14 pm

Do I understand correctly that CVOR messages only very rarely coincide with missing uploads?
However, I do not understand the process of error correction in the RP.
Here is a link to the code where the frequency correction is applied:

https://github.com/pavel-demin/red-pita ... les.c#L126

Basically, the DDS frequency is calculated using the following expression:

freq_dds = (1.0 + 1.0e-6 * corr) * freq

where corr and freq are the values read from the configuration file.

John Loftus
Posts: 6
Joined: Fri Mar 04, 2022 12:49 pm

Re: Correction value is out of range

Post by John Loftus » Sat Mar 19, 2022 3:15 am

Hi Pavel,

Thank you for looking further into this CVOR puzzle.

Firstly, I have not been able to reproduce any configuration where I can monitor lost spots due CVOR.

Secondly, the CVOR pattern is for the most part not random. There is a regular pattern of clusters through 24 hours of every day. The influence of slow changes in temperature is probably part of the puzzle.

The question becomes what is the impact of each CVOR event?

I think I can now see what is happening.

My understanding and theory:

Frequency drifts due to change in temperature.
When drifts reaches the threshold where CVOR kicks in, a correction is made. The amount of correction is limited to the original number in cfg file.

This method may create a sawtooth pattern to median value of frequency. If the sawtooth pattern endures during the two minute cycle, then swings in frequency may be enough to destroy decoding.

I have witnessed swings of more than ten Hz when viewing the grafana site at:
https://wspr.live/gui/d/0SsoVzUZk/rx-st ... cy?orgId=1

This swings could be minimised by making no correction at the threshold of CVOR, rather than reverting to the value in the cfg file. In other words, let the frequency continue to drift in a smooth fashion. Of course, transmissions at the edge of the 200Hz bandwidth would be missed.

It's hard to say if a relatively smooth drift is a better compromise compared to losing a larger chunk of what remains inside the 200Hz bandwidth. Other considerations include:

1) correction period - shorter correction periods may result in smaller swings.
2) correction value - smaller correction value may result in smaller swings.

A smaller correction value is an easy set and requires no change in the coding.

Your thoughts on the puzzle?

Regards
John

John Loftus
Posts: 6
Joined: Fri Mar 04, 2022 12:49 pm

Re: Correction value is out of range

Post by John Loftus » Sat Mar 19, 2022 3:30 am

Hi Pavel,

Further to my previous post,

A good example of the extent of frequency deviation is at:
https://wspr.live/gui/d/0SsoVzUZk/rx-st ... ar-band=28

With an upper quartile range of 12Hz and a lower quartile range of -15Hz.

Cheers,
John

pavel
Posts: 786
Joined: Sat May 23, 2015 5:22 pm

Re: Correction value is out of range

Post by pavel » Sat Mar 19, 2022 12:45 pm

I do not think the problem is related to the temperature change. The accepted correction range is -100 ppm to 100 ppm. It is about 10 times greater than the normal correction range.

After a few minutes or a few tens of minutes of operation, the board reaches its normal operating temperature, which is quite stable. When the correction measurement error occurs, the previously measured correction is used. Since the operating temperature is quite stable, the measured correction does not change significantly from measurement to measurement. So, the previously measured correction should be the same as the one that could not be measured. At least that is how it works with the default configuration.

If the measured frequency correction changes significantly from measurement to measurement when the board temperature is stable, then I think there could be a problem with the PPS output of the GPS module.

pavel
Posts: 786
Joined: Sat May 23, 2015 5:22 pm

Re: Correction value is out of range

Post by pavel » Sat Mar 19, 2022 6:29 pm

I think I caught an interesting case:

Code: Select all

Sat Mar 19 16:47:01 UTC 2022
-5.85
Sat Mar 19 16:49:01 UTC 2022
-5.85
Sat Mar 19 16:51:01 UTC 2022
18.21
Sat Mar 19 16:53:02 UTC 2022
Correction value is out of range.
Sat Mar 19 16:55:02 UTC 2022
Correction value is out of range.
It seems that the transition from correct correction (-5.85) to out-of-range correction is not immediate. Before going completely out of the range, it passes through a bad intermediate correction value (18.21).

Since the last measured value is severely wrong, the receiver will tune to the wrong frequency and miss most of the spots while the correction remains out of range.

To me this still looks like a problem with the PPS signal and a solution would be to somehow detect when the PPS signal cannot be used and measure the frequency correction only when the PPS signal is OK.

John Loftus
Posts: 6
Joined: Fri Mar 04, 2022 12:49 pm

Re: Correction value is out of range

Post by John Loftus » Sun Mar 20, 2022 2:17 pm

Thanks Pavel,

I think you have solved the puzzle and found a potential solution - great!
Your findings are consistent with my experience when correction value is out of range.

How did you modify the log printout to show the correction?

Cheers,
John

pavel
Posts: 786
Joined: Sat May 23, 2015 5:22 pm

Re: Correction value is out of range

Post by pavel » Mon Mar 21, 2022 8:39 am

I checked the PPS signal with an oscilloscope when the error messages appear. The PPS signal is OK.

I think I found and fixed the source of the problem in the axis_pps_counter with this commit. It seems that the problem was triggered when the program measuring the frequency correction started during the PPS pulse and the counting of the clock pulses started immediately instead of waiting for the next rising edge of the PPS pulse.

I have the new version running for over 7 hours without any errors.
How did you modify the log printout to show the correction?
All printouts from the update-corr.sh script are written to the log file. So I added the following command to the update-corr.sh script to print the correction value:

Code: Select all

echo $CORR

Post Reply
jadalnie klasyczne ekskluzywne meble wypoczynkowe do salonu ekskluzywne meble tapicerowane ekskluzywne meble do sypialni ekskluzywne meble włoskie

Who is online

Users browsing this forum: No registered users and 4 guests