Mega4809 TCA Oddity

Go To Last Post
48 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greetings Freaks -

 

I have been playing with the  RTC and the TCA peripherals, as I will describe. It has been a bit like a puzzle that  does not have all the pieces!

 

Here is what I have been trying to do. I'm trying to figure out a way to determine the calibration correction for a crystal-based 32.768KHz RTC. Because this will rely on an external time reference (note: probably GPS module with 1pps output), I want to make sure that all of the required ins and outs for this part are accounted for before proceeding with other parts of the project. Here is what I plan on doing. This is for calibration only, and not for normal operation.

 

  1. Clock source to be calibrated is a 32.768KHz crystal connected to Mega4809 (XOSC32K).

  2. Oscillator output is routed to RTC with no prescaling and no active correction

  3. RTC.CNT is enabled via RTC.CTRLA RTCEN bit

  4. Period is set to 0X1000, just for development. It will eventually be 0xFFFF.

  5. RTC overflow is assigned as the Generator for EVSYS.CHANNEL0

  6. EVSYS.CHANNEL0 is assigned user EVOUTB which routes the signal to PB2 which I observe with logic analyzer

  7. EVSYS.CHANNEL0 is ALSO assigned user TCA0. which is capable of providing clock input to TCA0. In code, the following is used:

             

	TCA0.SINGLE.EVCTRL = TCA_SINGLE_EVACT_POSEDGE_gc | TCA_SINGLE_CNTEI_bm;

  8. An approximately 1pps signal (generated by a TCB, which does not appear to be relevant) is generated as a surrogate for the future precision 1pps time reference

  9. The 1PPs signal is counted. After an arbitrary number of counts (4, in this case), the RTC is turned on via RTCEN bit and is turned off, using the same bit after a

       total of 16 1pps pulses. This  "gate" signal is also routed to a port pin for observation wth the  LA.

 10. After the count is stopped, the RTC.CNT register is read, as is TCA0.CNT register.

 11. TCA0.CNT ALWAYS shows 35. The logic analyzer ALWAYS shows that there were 38 pulses going into TCA0.

 12. I can change the period of the RTC OVF pulse coming, via EVSYS, from the RTC (by changing RTC.PER). Halving RTC.PER to 0x0800 doubles the number of

       missed pulses! That suggests something time (or system clock) related.

 

Image, below, shows the Logic Analyzer display with RTC.PER = 0x0800

 

 

Note that the RTC OVF pulses (LA Channel 1) begin exactly when expected and stop exactly when expected. Gate signal is LA Channel 0. TCA0.CNT = 70 but a software count of the pulses shows 76 and a manual count shows the same.

 

I DO have an alternative which is heavier on the  software so this is not catastrophic. However, something just does not seem "right". I can post code, though I will have to heavily edit it do remove copious development notes. 

 

Thanks for your time and your thoughts....

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Mon. Aug 3, 2020 - 10:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If I do that, use TCB.
Subtract the first capture result from the 61 second capture result.
If 32k is accurate, it should be 0x8000.
Since the total number of counts is 1,998,848, the error resolution is about 0.5 ppm.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I agree that probably TCB is better for this, however the mystery still needs to be investigated.

I think I would do a software count, via an ISR triggered by the PB2 rising edge (the same edge that supposedly advances timer A count), the ISR would log both it's internal count and the timer A count. Then, output the log via serial once the count is done. Comparing the ISR software count and the timer count should provide some clues.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't see how TCBx will work with the external crystal XOSC32K oscillator. TCBx, as far as I can tell, will work only with CLKPER or with TCA clock. XOSC32K appears ONLY to work with RTC.  It is NOT obvious if it will work with the event system as a clock to TCA. It does not seem the XOSC32K will work work as SYSCLK.

 

Is there another way?

 

Thanks

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Tue. Aug 4, 2020 - 04:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simply use XOSC32K as SYSCLK.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ahhhh!

 

Thank you. Missed that. CPU would run SLOOOW during cal but that is probably OK.

 

Jim

 

 

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This has morphed from the original question, which  I do need to research more (and will). 

 

But, on the suggestion by kabasan and El Tangas to run the whole cpu at 32KHz during the calibration count, I have DOUBTS. Yes, real doubts, even though I have previously railed agains the use of the term "doubt" in many  postings. Here, I think that it rises to the level of "actual doubt".

 

The doubt is based on the cpu executing code on the same time scale as the events being counted. This arises from several situations:

 

1. A 16 bit counter is NOT sufficient to accumulate 1E6 counts (0xF4240). A minimum 20 bits is needed, and more if we want a count interval that is close to an integer number of seconds long (in blocks of about 1E6). Events don't work with TCBx overflow, only capture. Thus, interrupt will have to be used to tally overflows. Having an interrupt with latency that is multiple count events long, plus an execution time that will be several 10s of count events long, makes me shudder.

 

2. I need to use a dumb 1pps timing reference. Thus, counting of multiple seconds for gate time will have to be an integral part of the calibration process. Doing this with a timing granularity of the events being counted makes me really uneasy, doubting that an accuracy within a few event periods is even possible. 

 

I am trying to provide a calibration number that will put the scaled 32.768KHz clock within maybe 10ppm, or even a little better if possible. That means that if 1E6 calibration counts are accumulated, that count has to be correct within a few counts. 

 

Any solutions for these questions? Or, are my doubts unjustified?

 

Thanks

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jim, have you seen AN2633? It's not *exactly* what you want to achieve but I think that there are enough clues in there to help you achieve what you want.

 

On the other hand, having not had a coffee for many hours, I might be completely off.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have that but have not read over it carefully. Clearly, need to do that, now. Sufficiently caffein-enhanced, here.

 

Thanks for the pointer,

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

1. A 16 bit counter is NOT sufficient to accumulate 1E6 counts (0xF4240). A minimum 20 bits is needed, and more if we want a count interval that is close to an integer number of seconds long (in blocks of about 1E6). Events don't work with TCBx overflow, only capture. Thus, interrupt will have to be used to tally overflows. Having an interrupt with latency that is multiple count events long, plus an execution time that will be several 10s of count events long, makes me shudder.

 

2. I need to use a dumb 1pps timing reference. Thus, counting of multiple seconds for gate time will have to be an integral part of the calibration process. Doing this with a timing granularity of the events being counted makes me really uneasy, doubting that an accuracy within a few event periods is even possible. 

 

I understand your worries. So, reading kabasan's proposal and AN2633 mentioned by Brian, maybe it will be possible to use the 1 pps source to drive the RTC via extclock, set the RTC to count 61 1s pulses, and use TCB to capture the length of this interval.

Of course TCB will wrap around several times (every 2s) so, 30 times, and will be about halfway through the final count when the RTC finishes. But the high bits are not important anyway, they don't need to be recorded since we only expect deviations on the low bits.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good point.

 

Will think that strategy through in more detail.

 

Thanks

Jim

 

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Why not make things a lot easier & just pipe the clock into a freq counter?  I took a $250 dollar counter & got the following in about 5 minutes of fiddling:

(32 KHz from a sig gen)

 

32768.0212 Hz @ 1 second per reading (9 digits/sec)

32768.02126 Hz, @ 10 seconds per reading

32768.021258 Hz, @ 100 seconds per reading

 

It drives me a bit nutty that I don't measure all zeros  (well, that would be asking for a lot)...the gen is off a bit, more so than the freq counter.

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies - That setup is very nice but there is a big flaw. You stll have to determine the correction constant and implement it in code. That number will be different for every unit. So, nice external counter is a non-starter.

 

Brian's suggestion of the AN on calibration of the internal low frequency clock reminded me of several facts that I had just plain over-looked (e.g. forgotten):

 

1. You don't have to keep track of over-flows if the variation of the signal being counted is sufficiently small. The criterion is that the over-flow is the same under all conditions.

 

2. When a fast signal is being  compared to a slow signal, either one can be the unknown one. I had fixed in my mind that the calibrated one HAS to be the slow one and the uncalibrated one HAS to be the fast one. Not So! Duuuh! 

 

The business of slowing FCPU to 32KHz is a killer for periodic run-time corrections if you need to do things like maintain a sensor sample rate or maintain a time-of-day. 

 

The AN from Brian's suggestion does show how to use the capture capability to do what I want to do, and THAT is really useful.

 

The saga continues. Still have not sorted out the original problem with TCA. 

 

Thanks

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You stll have to determine the correction constant and implement it in code. That number will be different for every unit.   So, nice external counter is a non-starter.

Well of course, each unit will be different, so that is why you want to calibrate them...I'm assuming you have some way of entering calibration commands & storing the cal values---is that not something you can have? 

 

something like:

CALMODE (enables calibration)

 

TCAL2387 (cal number to give corrected timebase).  Based on observed measurement

 

CALSAVE  ...store the cal value(s) in EEPROM or flash

 

   ....all done!

 

You could also get there by having up down buttons, menus or blinking leds and the like, but  a terminal is much more flexible.

 

You will need SOME way of entering a cal value regardless of what means of measuring (and parameter entry) you employ---you must store a calibration value of some sort.  That isn't much different from entering & storing other factory/user config information (serial number, language, shutdown time,  buzzer volume, transmitter power level....you name it). 

 

Am I off-base, or simply sleep deprived?

 

 

  

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Thu. Aug 6, 2020 - 01:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My goal is to connect a precision 1Hz signal. Then, with the terminal enter "CAL" or something, then a minute or three later, a LED would  come on, signifying that the calibration value has been determined and stored in the EEPROM.

 

Done. No numbers to enter, no entries to make errors with. Anybody, including me, can do it. Maybe even when I am senile (not so far away!).

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 No numbers to enter, no entries to make errors with. 

That self-cal might be a noble goal.  The systems we work on usually have a number of entries  for ilinearization, optional parameters like alignment, etc. In some cases we hook it to a PC (interactive control panel), if it is a moderate size table or amount of info.  So our mindset is we will be entering  a variety of things.  Interestingly, some units may be triple the cost of other units (say $250 vs $500 Vs $750), but they are the exact same physical unit.  Only the cal entries and a few other selections turn the $250 unit into a $750 unit...Until the Chinese jump in with a $35 unit and everything tanks. 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Thu. Aug 6, 2020 - 01:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I expect 3 versions of this product:

 

1) Using the MCU-based RTC but with basic room temperature calibration. It will have some positive offset at 25C so that it will have nearly zero average error at the equinoxes. No attempt to temperature compensate. No backup battery. Marginally improved over the existing product.

 

2) Plugin board with RTC chip, crystal, and backup battery. Chip has first order temperature correction. It will take "calibration" much like the internal RTC. Significantly better than current product over full temperature range.

 

3) Plugin board with crystal and RTC chip in single package plus backup battery. Significant temperature correction. Good for about +/-6ppm over full temperature range making it a major improvement over current product. Factory calibrated. MIGHT serve as a calibrated source for first two options in the factory.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

This is an example I made about two years ago.
It is equipped with tiny1616, RTC (PCF2129AT) and liquid crystal.
RTC is backed up by CR2032.

 

It has a function to automatically correct with 1PPS of GPS, and you only need to connect the GPS module and operate the buttons. The correction step is 1ppm unit, and mine was the correction result of -2ppm.

The LCD screen in the photo shows the date of the correction, about 10 months ago.

When I turn on the power for the first time in 10 months. The gap was just 1 second.
Cumulative for 10 months, resulting in 0.04ppm.

 

Last Edited: Thu. Aug 6, 2020 - 06:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Very impressive...

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kabasan wrote:
Cumulative for 10 months, resulting in 0.04ppm.

 

Nicesmiley But you got lucky, right? If the adjustment step is 1ppm you can expect to be within 0.5 ppm of the exact value after correction as a worst case scenario, if I'm seeing things correctly.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
Factory calibrated.
One at the PCBA manufacturer may not want that as a requirement (efficiently process a lot such that can switch to the next customer)

Calibration is "usually" a logistics activity (receivable and/or deliverable (inventory or at/by customer), provisioning at operator)

 

P.S.

re backup battery, there are RTC that can run on some MLCC though would need evaluation for these may not meet the required tolerance versus time.

Ultra-Low Power RTC (Ambiq Micro)

edit : second source

Abracon | Abracon’s Industry Leading 22nA Time Keeping Current…

 

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Thu. Aug 6, 2020 - 04:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

if we say your normal run the AVR with the internal 16MHz clk.(and have a free running timer at that speed)

 

Then find out how many clk's there are in 1 sec from the 1 pps (even just with SW loops this can be done with a jitter of max 4 clk or 0.25ppm)

At the same time measure the time from 1sec from the RTC (If you fear that the 16MHz change start RTC when the 1pps have an edge).

 

Now you have two numbers there should be close to each other (you will only need the lower 16bit of the 16e6 counts). And based on that you can find a calibrated value for the RTC, or perhaps do your own compensation.  

So with this you should get something better than 1ppm.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have experimented.
The internal oscillator had very large fluctuations, and even if it was captured with the 1PPS trigger, the values were very different each time, which was very useless.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But it's just the time difference between 1pps GPS and 1sec form RTC that matter here, so if you do the calibration of the RTC while the 1pps is connected the only thing you need to know is: is the RTC to slow or to fast, make an adjustment and try again.(that will take more tries but will work)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I do not expect the assembler to do ANY electrical configuration including device programming. So #21 does  not make much sense.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some PCBA manufacturers will have a jig to test the PCBA.

Programming is typically a bootloader plus a Built-In-Test (BIT) application though there may be calibration.

 

GitHub - microchip-pic-avr-examples/avr128da48-tuning-internal-hf-osc: Internal High-Frequency Oscillator Calibration Using the Auto-Tune Feature

via Internal High-Frequency Oscillator Calibration Using the Auto-Tune Feature

via AVR128DA48 - 8-bit AVR Microcontrollers

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

At MY CM, I choose to do the finish work. They build the board, not the  product.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Jim,

 

Taking a few liberties, here is my assessment of the problem statement:

1) mega4809 using external 32 kHz oscillator to drive the RTC

2) for periods on the order of seconds to minutes, a reference source of 1 PPS will drive interrupts on the port of choice (e.g., can be high-priority interrupt -- interrupt jitter will affect the error)

3) you want to use the reference source to determine (A) scale factor correction for the RTC and (2) bias correction for the RTC based time

4) the requirement driving the period (2) is the error in scale factor

5) you don't care if the bias correction gets implemented after the end of calibration period in (2)

 

My approach to this would be to assume that your RTC implementation keeps a second counter (i.e., every 32000 ticks it fires an interrupt to increment the seconds).  When the reference generates an interrupt we can sample (1) the second counter and (2) the RTC count.  We run with the 1 PPS reference until the estimates scale factor correction is good, then fire LED, then start the bias correction via change in the calibration register, once the bias correction is complete, we update the calibration register with the correct value from the scale factor correction.

 

Work to go is to generate an algorithm to generate the scale factor and bias correction.

 

Matt

 

EDIT: In the above I am using the term scale factor to refer to the calibration register value, which provides in a sense an adjustment of the clock frequency.

Last Edited: Fri. Aug 7, 2020 - 03:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Right now, the only board in my hand with a 32K crystal is the AVR128DA28.

This XOSC32K generated an event every 10 seconds via RTC and captured 24MHz of SYSCLK 11 times in a row.

The XOSC32K does not have 32678Hz accuracy because it is uncalibrated, but because it is a crystal base, there should be little fluctuation.

 

This is each capture interval and its fluctuation.

(Based on the first result)

Please look at CLKOUT of the internal oscillator of mega0 with an 8-digit frequency counter.

 

It was good to be able to experience the TCB's 32-bit mode in this attempt.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did not know that the DA chips have a 32 bit TCB mode. The M4809 does not seem to (at least not  listed in "Features"). 

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But you don't really need to 32 bit for this kind of things.

If you know that you are close in freq the low 16 bit will tell all you need. (if you don't know if you are close you can just fire an overflow ISR (then you would be blind in about 20 clk, but that's only about and error of 1ppm)).

 

But my suggestion of 1pps and 1sec RTC will only see and error of about 50 clk of the internal 16/20 MHz not all the 16000000 clk's 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
8. An approximately 1pps signal (generated by a TCB, which does not appear to be relevant) is generated as a surrogate for the future precision 1pps time reference

 

Then you are clocking this TCB from TCA, or else you wouldn't be able to generate such low frequency pulses. What divisor are you using for TCA? Maybe if the RTC frequency is higher than TCA frequency this causes some event pulses to be missed, because they are shorter than a TCA clock? 

 

In fact I wouldn't be surprised if TCA needs to be running at > 2x 32768Hz to be able to sample the RTC pulses correctly. My math sense (which is admittedly very fallible) is whispering Nyquist...

 

I think you should generate the test 1pps signal externally somehow, because if you use a TCB, it will necessarily be running from a TCA set to <= 65.536kHz.

Last Edited: Sat. Aug 8, 2020 - 01:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

At the present time, an internal 1pps signal (as a surrogate for the  precision 1pps signal to be supplied externally later) is created by counting down the MCU clock (Mega4909 Xplained Pro, 16MHz/2 = 8MHz) to 250Hz, then software down-counting to 2Hz and toggling a port pin to make a 1Hz signal. Of course, it is quite inaccurate, but as long as it is close enough, the algorithm should not care.

 

I've just discovered a signal pathway that will allow counting either the internal 32KHz clock or an external one while maintaining the CPU clock frequency at 8MHz. It goes like this:

 

1) Either of the 32KHz clock sources can be connected to the clock input of RTC.

 

2) RTC can be set to overflow at some small down-count from its clock input. Hopefully, that will be divide by 2 but a slightly higher division can be tolerated.

 

3) RTC OVF output can be a  generator for the event system.

 

4) The event system CAN be the clock input for TCBx.

 

5) Capture input will be driven by the 1pps reference signal, or its lower accuracy surrogate

 

6) Capture  value will be recorded from two capture events some seconds apart (the time difference will be chosen depending on the needed count resolution for clock correction). Overflows might be counted or simply assumed if there is no chance of two different overflow values based on the maximum possible difference between the reference clock and the clock being calibrated.

 

All this is being implemented right now. Will report on how it works out.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

3) RTC OVF output can be a  generator for the event system.

 

4) The event system CAN be the clock input for TCBx.

 

Whoa, it's true. Getting a clock from RTC -> TCA -> TCB is an interesting exercise. It took me quite a while to figure it out, but finally I have a 16kHz square wave being output from both the RTC and TCB from the same 32kHz clock.

 

It took me more time than it should, because this bit of fake news in the mega4809 datasheet misled me:

The COUNT event user is enabled on the peripheral by modifying the Clock Select (CLKSEL) bit field in the Control A (TCBn.CTRLA) register to EVENT, and setting up the Event System accordingly.

This was probably copy/paste from the AVR-DA datasheet, which actually have this capability to clock TCBx directly from events. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I re-discovered this GPS module, $40, which has a 1 PPS output.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas - thanks for that bit of exploration. I am heading down the same path right now.

 

MattRW - i spotted that just a few days ago. That is really close to what I have been looking for and will probably "do".

 

Thanks, both of you!

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Watch out & verify your source of 1 PPS signal..just because it says 1 PPS, may only mean accurate over a long time interval...so some care & vigilance is a must (or a datasheet with a guaranteed short-term accuracy spec).

 

The GPS receivers manufactured for timing applications or geodetic class GPS
receivers provide a 1PPS signal with an accuracy of up to 10 ns for 5 day average values, according to the manufacturers' specification.

This accuracy is often misunderstood as the accuracy in real-time, which is much worse due to the large noise in the GPS signal.

CONCLUSIONS AND REMARKS
According to overall results of our 24 hours measuring session, it can be concluded that a geodetic class GPS receiver
is capable of permanent delivering time marks within ms accuracy. Examples of such application are permanent monitoring of an industrial process, or time synchronization
between distant computer nodes in a wide-area network. Still, when higher accuracy is needed, in the order of microseconds or better, a special attention should be paid to the set-up of the equipment,....

 

we did not find what caused the outliers in the 1PPS coming from the NetRS. They do not affect the everyday use of NetRS (surveying, positioning, and time-keeping in LAN), but could seriously degrade the accuracy of certain time critical applications.

===================

The Sparkfun module uses a Micro Modular MN1010 GPS receiver module, which has a 1PPS output that isn’t brought out to a header or even a convenient pin, so I used some microsurgery and very fine wire.

The results!

MN1010 1 PPS output Just terrible! The pulse period jumps from around 980 to 1002 ms.

===================

elsewhere:

The underlying noise due to granularity of the clock generating the 1 PPS signal is deterministic on every pulse. The sum of these errors can be as low as a few tenths of a microsecond up to a few microseconds, depending upon the receiver manufacturer and design.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sat. Aug 8, 2020 - 08:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for that warning. That is not easy information to find!

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Those GPS's used in AIS systems use the 1pps signal, and that is the sync. signal for when you can send a packet.

I don't have the max error in time here but it's small.(a hole packet is only 33ms an the error from time should be <<1ms)

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


 

In case someone might find it useful, this is my test program, routing external 32kHz crystal -> RTC -> TCA -> TCB on a mega4809 (Curiosity Nano dev board).

The program outputs 3 16kHz square waves: one from the RTC (on PA2), which is directly clocked from the crystal, one from TCA0 (on PA0, same phase as RTC) and one from TCB1 (on PA3, inverted phase).

 

#include <avr/io.h>

void set_clock(){
  _PROTECTED_WRITE(CLKCTRL.XOSC32KCTRLA, CLKCTRL_RUNSTDBY_bm | CLKCTRL_ENABLE_bm);      // Enable 32kHz crystal; run in standby is needed.
  _PROTECTED_WRITE(CLKCTRL.MCLKCTRLB, CLKCTRL_PDIV_2X_gc | CLKCTRL_PEN_bm);             // Prescaler.
}

void RTC_init(){
  // The RTC is programmed to generate an event every other clock cycle, clocked by a 32kHz crystal.
  // Since each event pulse takes one RTC cycle, this means a square wave of 16kHz is generated on the RTC event output.
  RTC.CLKSEL = RTC_CLKSEL_TOSC32K_gc;
  RTC.PER = 1;
  RTC.CTRLA = RTC_PRESCALER_DIV1_gc | RTC_RTCEN_bm;
}

void EVSYS_init(){
  // Route the 16kHz square wave from RTC to both EVOUTA (PA2), for observation, and to the TCA event input, to clock TCA.
  EVSYS.CHANNEL0 = EVSYS_GENERATOR_RTC_OVF_gc;
  EVSYS.USEREVOUTA = EVSYS_CHANNEL_CHANNEL0_gc;       // Port direction is overridden automatically
  EVSYS.USERTCA0 = EVSYS_CHANNEL_CHANNEL0_gc;
}

void TCA_init(){
  // Generate square wave at TCA clock /2 on TCA output 0 (PA0).
  TCA0.SINGLE.CTRLB = TCA_SINGLE_CMP0EN_bm | TCA_SINGLE_WGMODE_SINGLESLOPE_gc;
  TCA0.SINGLE.CMP0 = 1;
  TCA0.SINGLE.PER = 1;
  PORTA.DIRSET = 1 << 0;      // Set PA0 as output. This is not automatic for TCA.

  // This basically sets the TCA event input as clock.
  // Both edges clock TCA, this allows the 16kHz square wave coming from RTC to clock TCA @32kHz, thus recovering the full crystal clock.
  TCA0.SINGLE.EVCTRL = TCA_SINGLE_EVACT_ANYEDGE_gc | TCA_SINGLE_CNTEI_bm;

  // Enable TCA. The divisor seems to be ignored, the clock is set by the event input.
  TCA0.SINGLE.CTRLA = TCA_SINGLE_CLKSEL_DIV1_gc | TCA_SINGLE_ENABLE_bm;
}

void TCB_init(){
  // Generate square wave at TCB clock /2 on TCB1 output (PA3).
  // Enabling TCB output also automatically overrides port direction, unlike TCA.
  TCB1.CTRLB = TCB_CCMPEN_bm | TCB_CNTMODE_PWM8_gc;
  TCB1.CCMPL = 1;
  TCB1.CCMPH = 1;

  // Clock TCB from TCA, therefore indirectly from the 32kHz crystal.
  TCB1.CTRLA = TCB_ENABLE_bm | TCB_CLKSEL_CLKTCA_gc;
}

int main(void){
  set_clock();
  EVSYS_init();
  RTC_init();
  TCA_init();
  TCB_init();
}

 

The outputs of TCA0 and TCB1 have a 3 CPU cycle phase delay relative to the RTC (crystal) plus jitter of 0-1 CPU cycles, as can be seen here:

 

 

This delay depends only on the main clock; Setting divisors on the TCA0 prescaler seems to have no effect.

 

edit: zoom out

 

Last Edited: Sat. Aug 8, 2020 - 09:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My suggestion of TCB counting events is NOT correct. It WILL NOT work.

 

It appears that TCB will ONLY use an event input to do a capture.

 

So much for that "pathway"!

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How about replacing it with DA48?
TCD is best suited for this application.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Considering that.

 

In the mean time, I just discovered that the event system CAN be the clock for TCA AND CLK_TCA CAN be used as the clock for TCB. Then again, this is exactly what El Tangas described up in msg #40!

 

Of course, this uses a lot of resources, BUT, if this is a one-off, calibrate in manufacturing only, then all those can be available for other uses at user run-time.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is an idea.  I don't know if the CCL has enough to support or if the timers can do it:

1) run system clock at 8 MHz, as you wish

2) 1 PPS external signal generates an interrupt on pin X.

3) 32768 Hz osc drives RTC

4) RTC generates interrupt every fourth cycle

5) CCL is used to generate a signal with rising and falling edge (possible?)

6) use TCB in time-out check mode to measure number of cycles from PPS to next RTC/4

7) each second, on interrupt from TCB,

7a) compute the number (integer and fractional) sys clock ticks from PPS to RTC/4

7b) compute the difference from the last (7a) computation

7c) keep running average of the differences in (7b)

7d) keep running average of the variance of samples from (7b)

8) generate CALIB

9) compute offset and adjust for that (instantaneous or over some long term)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Worked nicely with  El Tangas' code. Had to modify slightly for 4809 Xplained Pro board which has no 32KHz crystal. Just changed a the set_clock() to use not turn on the external 32KHz oscillator and changed RTC_init() to use the internal oscillator instead of external one. While the accuracy is not sufficient for the final application, it demonstrates the logical operation quite adequately.

 

Thank you El Tangas ...

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Should point out that El Tangas' nice little sample code block really deals with the issue of clock distribution to get a TCB to count from either of the 32.768KHz clocks (internal and external). The code uses TCB in split mode because 8-bit PWM seems to be the only mode where you can get a direct indication of counter period for viewing on an oscilloscope or logic analyzer.

 

What you do with that TCB is up to your ingenuity. 

 

In the context of the original question, I am going to use TCB in one of the capture modes, driven by processed external 1pps signal. That 1pps signal will be "processed" to make a count gate that is around 1E6 clocks long. In this case, due to inevitable down-counting in RTC, that clock frequency is 16.384KHz. The gate will be 61 seconds long which is tolerable for the application and close enough to 1E6 counts long. Using the EVSYS.STROBEx, the software generated gate will trigger capture events for TCB. The capture value will be combined with an assumed or deduced roll-over count to create an effective 32-bit count that can then be processed to determine the appropriate correction value to be used in RTC.CALIB.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you are still interested in generating the RTC CALIB value from an external 1 PPS pulse, I may have a solution using

1) the RTC

2) two event channels

2) two TCBs

Working out some code now, and I have a signal generator that should be able to generate a 1 PPS square wave.  I think it should be simple (but that's not always how things turn out).

 

I  was working another angle with the PIT.  While that works to generate an estimate of the clk_per ticks per RTC/PIT, I don't think it will translate to solving this problem.

This has been a great experience getting familiar with the event system.  It seems like a great resource.  It's a bit like a publish/subscribe capability.   And having multiple TCBs seems to be very useful.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Working on a similar method, I think. Happy to compare methods in a fairly short time.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!