ATtiny202 - External Oscillator Circuit

Go To Last Post
103 posts / 0 new

Pages

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

Are you sure your boost converter is not going silly at low temperatures? I’ve been battling such issues at the office recently. Class 2 ceramic caps get worse at low temps.

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

A freq counter is the best bet---cheap & super accurate & made for the task. Who wants to to look at a cursor to read 24.7347 Hz

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

There are some relatively inexpensive USB frequency counters.

 

XMEGA AVR have a high frequency DFLL with an input from USB SOF (1KHz); full speed USB 2 is 2500ppm (0.25%)

 


DDS3X25 - Hantek

 

USB in a NutShell - Chapter 2 - Hardware | Data Signaling Rate

 

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

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

avrcandies wrote:

A freq counter is the best bet---cheap & super accurate & made for the task. Who wants to to look at a cursor to read 24.7347 Hz

Frequency counters are great for measuring averages of continual pulse trains.

Some of the better ones can do edge-edge timing.

 

They are not so great at measuring jitter and periods over short bursts of data.

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


I have measured the frequency by toggling "LED" PIN on the ATtiny202. But this is not very accurate. The frequency is constantly changing. Only two decimal places do not change. The short loop needs 3 CPU clocks i.e. 20M / 3 = 3.33 MHz.

 

!int main(void)
!{
!	/* Initializes MCU, drivers and middleware */
!	atmel_start_init();
0x3D: RCALL atmel_start_init
!	/* Replace with your application code */
!	while (1) {
!        PORTA.OUTTGL = PIN1_bm;
0x3E: LDI R30, 0x00
0x3F: LDI R31, 0x04
0x40: LDI R24, 0x02
0x41: STD Z+7, R24
0x42: RJMP 0x41

I can't add media, Oscilloscope picture, why ? You are not authorized to access this page.

Oscillations are due to the large loop of oscilloscope probe wires.

 

[moderator: not sure why you couldn't add this but here it is anyway...]

 

Attachment(s): 

Last Edited: Thu. May 6, 2021 - 09:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They are not so great at measuring jitter and periods over short bursts of data.

I have a freq counter that will give min/max and frequency standard deviation to 100ps.  I never notice when my pulse is 100ps late!!

 

There are also time interval analyzers that will give frequency histograms & very detailed analyssis:

The 5371A uses a continuous measurement time sampling technique to quickly capture and display data. By eliminating reset time, measurement throughput is dramatically increased to more than 10 million measurements per second with a frequency range of up to 500 MHz. The 5371A can help you analyze jitter effects, characterize the transient and steady state responses of a VCO, examine frequency or phase modulation, measure frequency stability, analyze computer peripherals, or measure fast hopping radio signals. 

  • Calculated Allan Variance specifies frequency stability in the time domain
  • Broad selection of measurements
  • Graphic display and histograms add visual meaning to numbers
  • Excellent single-shot 10-digit resolution at 150 ps rms

 

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

 But this is not very accurate. The frequency is constantly changing.

Some of that can be the AVR RC timebase is often not super-steady cycle-to-cycle. 

You scope hook up need some tuning or proper termination!!

 

When the Rigol meas freq is it doing it over 1 cycle? 10cycles? 1000cycles? (width, not separate sweeps)   The wider the meas interval, the steadier, since wiggle is averaged out & trigger time inaccuracies are less of a percentage of the wider result.

That's a benefit of a freq counter, it doesn't have to store a billion points of data, so it can use a longer time window with little overhead (as one of several counting methods).

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

Last Edited: Thu. May 6, 2021 - 10:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

When the Rigol meas freq is it doing it over 1 cycle? 10cycles? 1000cycles? (width, not separate sweeps)   The wider the meas interval, the steadier, since wiggle is averaged out & trigger time inaccuracies are less of a percentage of the wider result.

 

I've got a GPS TXCO here so have done a few tests. The frequency 'box' on the scope is independent of the waveform display but I can see no way to alter the gate time which appears to be automatic.

 

Feed in a 10MHz signal and it displays 10.0001MHz. Feed in 1kHz and it displays 999.994Hz. So the software is trying to always fit the measured value within 6 digits and is moving the decimal point accordingly. And I guess to do that it must also be altering the measurement interval.

#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

avrcandies wrote:
When the Rigol meas freq is it doing it over 1 cycle? 10cycles? 1000cycles? (width, not separate sweeps)   The wider the meas interval, the steadier, since wiggle is averaged out & trigger time inaccuracies are less of a percentage of the wider result.

That's a benefit of a freq counter, it doesn't have to store a billion points of data, so it can use a longer time window with little overhead (as one of several counting methods).

I would reckon the frequency is measured based on number of pulses seen on the oscilloscope screen. In the picture above in 7 cycles.

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

It's working fine almost 98% of the time. Base station just sometimes rejects the data when the outside temperature is going low.

 

I can't add media picture inline into text. I have got: You are not authorized to access this page.

Attachment(s): 

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

Kevil wrote:

avrcandies wrote:
When the Rigol meas freq is it doing it over 1 cycle? 10cycles? 1000cycles? (width, not separate sweeps)   The wider the meas interval, the steadier, since wiggle is averaged out & trigger time inaccuracies are less of a percentage of the wider result.

That's a benefit of a freq counter, it doesn't have to store a billion points of data, so it can use a longer time window with little overhead (as one of several counting methods).

I would reckon the frequency is measured based on number of pulses seen on the oscilloscope screen. In the picture above in 7 cycles.

 

Not according to my tests. I can zoom in to just a small part of one complete cycle and it will still measure the frequency.

#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


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


Kevil wrote:

SNIP

 

But that's not the option you want. You want to select which channel the counter is getting its input from. Here it is measuring the frequency of several cycles of a 1kHz sinewave...

 

 

...and here from the same signal but note the horizontal timebase is now 10ns...

 

 

Note that the frequency counter hasn't changed.

#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

OK, It's looks like you are right. Unfortunately it doesn't solve my problem on how to measure 20 MHz precisely by oscilloscope.

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

Kevil wrote:

I have measured the frequency by toggling "LED" PIN on the ATtiny202. But this is not very accurate. The frequency is constantly changing. Only two decimal places do not change. The short loop needs 3 CPU clocks i.e. 20M / 3 = 3.33 MHz.

 

Hmmm, it shouldn't jump around. An RC oscillator might not be accurate but it should be relatively stable. Start by getting rid of that ringing on the signal and see what happens.

#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

Note that the frequency counter hasn't changed.

That's smart!!! My old $$$ tek TDS scope just says something like, not enough cycles to measure freq (though I haven't investigated the menus to look into it further)

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

Kevil wrote:

Unfortunately it doesn't solve my problem on how to measure 20 MHz precisely by oscilloscope.

 

Making accurate measurements is always a problem. How do you know that your test instruments aren't lying to you?

 

For frequency measurements I check against a GPS disciplined 10MHz oscillator which I bought on eBay for about 80USD. As well as providing a stable test signal it could also be used to make a frequency counter by using the other output it has which is a 1 pulse-per-second signal. Feed that into a chip and use it to start and stop a counter. Count the number of pulses of your unknown signal in one second and you have the frequency.

#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

Brian Fairchild wrote:
Start by getting rid of that ringing on the signal and see what happens.

It's an internal ATtiny202 oscillator.

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

Odds are, then, that the ringing is "fake" due to the ground lead on the scope probe. Or, maybe you do not have a ground connection AT the probe. You want a SHORT ground lead (few cm, max) from the probe to a ground point that is as close as possible to one of the MCU ground pins.

 

Jim

 

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

 

 

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

I know, but ATtiny202 is a very small SOIC-8 package. You can hardly connect the probe directly to any pin, I had to use breadboard wires with hook clips.  Although I have torsion spring ground probe for oscilloscope I can hardly hold it by hand on chip pins.

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

Kevil wrote:

I know, but ATtiny202 is a very small SOIC-8 package. You can hardly connect the probe directly to any pin, I had to use breadboard wires with hook clips.  Although I have torsion spring ground probe for oscilloscope I can hardly hold it by hand on chip pins.

Try a modest series R, so the probe does not connect straight to the pin.  eg 470R

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

Brian Fairchild wrote:

I've got a GPS TXCO here so have done a few tests. The frequency 'box' on the scope is independent of the waveform display but I can see no way to alter the gate time which appears to be automatic.

 

Feed in a 10MHz signal and it displays 10.0001MHz. Feed in 1kHz and it displays 999.994Hz. So the software is trying to always fit the measured value within 6 digits and is moving the decimal point accordingly. And I guess to do that it must also be altering the measurement interval.

 

Reciprocal counters measure over a nominal minimum gate time. (eg 10ms or 100ms) they then round that time up to the nearest whole cycles, and take CapturedCycles/CapturedTime to calculate frequency.

As such they autoscale and give a fixed number of digits per second.  A modest 10MHz counter clock, can give 6 digits in 10ms. 

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

There are silicon clock sources available these days - quite low power; eg, https://www.sitime.com/

 Are there any micropower oscillators that aren't in impossibly tiny packages?  say 0.65mm or larger for the smallest pin spacing?

 

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

Don't forget to adjust your probe compensation too (though this looks worse than that).  The R to dampen things sounds like a winner. 

As pointed out the flying gnd lead makes a nice ringer and loop antenna

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

Who-me wrote:
Try a modest series R, so the probe does not connect straight to the pin.  eg 470R

It's on the small PCB already. Have a look at the picture on the page 1 of this discussion smiley.

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


Kevil wrote:
... I can hardly hold it by hand on chip pins.
'IC cap' will fit onto the probe's barrel; working end has ears to locate onto the lead.

via 350 MHz X10 Scope Probe Ro | Pomona Electronics

 


PK007-012 Teledyne LeCroy | Mouser

 

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

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

Brian Fairchild wrote:

Kevil wrote:

I have measured the frequency by toggling "LED" PIN on the ATtiny202. But this is not very accurate. The frequency is constantly changing. Only two decimal places do not change. The short loop needs 3 CPU clocks i.e. 20M / 3 = 3.33 MHz.

 

Hmmm, it shouldn't jump around. An RC oscillator might not be accurate but it should be relatively stable. Start by getting rid of that ringing on the signal and see what happens.

 

Yes, RC oscillators are not great, but 2 decimal places is suggesting a quite poor one part in 300 jitter.

Usually RC oscillators are in the one part in 5000~20000 area, so you should have 3 to maybe 4 digits stable

I wonder if the ATtiny202 is well decoupled ? Maybe the OP can colder a cap directly across the package to see if that changes jitter ?

Last Edited: Thu. May 6, 2021 - 10:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kevil wrote:

Who-me wrote:
Try a modest series R, so the probe does not connect straight to the pin.  eg 470R

It's on the small PCB already. Have a look at the picture on the page 1 of this discussion smiley.

Not that I can see.

I'm talking about a series R on the data line, before it hits the scope probe capacitance.

Probes set 1:1 are worse ringing than scopes probes set 10:1

 

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

By chance I noticed In-Circuit Oscillator Calibrator for AVR Microcontroller. Maybe I can calibrate my ATtiny202 by means of STM32 clocked by external TCXO.

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

I would rule out a power problem as Kartman suggested earlier, before going through lots of clock work. Seems hard to believe the receiver is that fussy about the timing when its designed to account for a lack of precision in the timing. Get a pair of batteries to power the avr, bypassing the step up converter to see if its a power related problem. Not sure what the transmitter needs for power, but it is on/off and maybe at low temps going from off to on is too much for what  the power source can now provide, causing the tx to stumble.

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

 

curtvm wrote:
Not sure what the transmitter needs for power, but it is on/off and maybe at low temps going from off to on is too much for what  the power source can now provide, causing the tx to stumble.

The boost converter should be fine, it can provide up to 75mA@3.3V

I have measured the power consumption by XAM on SAMR34 Xplained Pro Evaluation Kit. It takes 20mA for 2x 162.8ms, then in the sleep mode 98.4 µA.

 

 

Last Edited: Fri. May 7, 2021 - 12:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

curtvm wrote:

 Seems hard to believe the receiver is that fussy about the timing when its designed to account for a lack of precision in the timing.

Yes, certainly Manchester is intended to be highly clock tolerant, but this is a refit of a closed proprietary system so I wondered if the vendor has done this deliberately (or accidentally) 

If you know you have crystals at each end, it is not hard to make your system more closed, by running a very tight baud spec.

(and you can do the same thing accidentally, by not ever checking for baud-span margin ;) )

 

The other aspect of the tests that worry, is the single-value working - ie no margin band visible.

Instead of /24, and /406, it would give finer baud steps to use /10 and  /976 etc, as the data shows a 10b divider.

The ideal is to find 3 or more values what work, and select the middle one.

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

Kevil wrote:

By chance I noticed In-Circuit Oscillator Calibrator for AVR Microcontroller. Maybe I can calibrate my ATtiny202 by means of STM32 clocked by external TCXO.

You could, but note that the step-size of the tiny202 trim, at about 1.4% in the data, is much larger than your indicated error tolerance.

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

>so I wondered if the vendor has done this deliberately (or accidentally) 

 

I'm sure one could figure out what errors could be tolerated assuming the receiver is just sampling at some exact interval (1/1024sec), after the preamble is seen. I think there are something like 134 bit times per frame excluding preamble if I'm reading the pdf correctly, so it could be to reliably get to the last bits you need to be <0.2% from what they are using. Like having a 134bit data uart.

 

The board looks like it has plenty of space for modifications if needed (most boards need modifications, that's why there is always a version 2). If a better clock ends up being needed, maybe something like a microchip DSC1004AI2-001.0000 can be used, hot glue to board pad side up, hook up a few short wires and have it run the ext clock input. Either use its standby feature or power it from a pin. Turn it on after wake, wait to stabilize, switch clock to ext, send data, turn off, clock back to internal, sleep.

 

You could also simply move to a warmer climate.

 

 

edit- I would still try the multiple baud value thing, using a clock divider less than /24 to give you more usable baud values. And back to some earlier post, you already know the temperature, so could work up a range of baud values that work at various temperatures so you can be more selective about the range of values used when sending.

Last Edited: Fri. May 7, 2021 - 05:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kevil wrote:
The boost converter should be fine, it can provide up to 75mA@3.3V

 

Even though incorrect parts were chosen and the layout has issues? I'd be ruling out the obvious first.

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

Kartman wrote:
Even though incorrect parts were chosen and the layout has issues?

I used the recommended parts from the Microchip Typical Application design. There are no issues with the boost converter smiley.

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

>There are no issues with the boost converter

 

At least at normal temperatures. Troubleshoot from easiest to hardest. Get a pair of aa/aaa batteries hooked up to bypass the boost converter- you then have a power source that you know is good. Problem either remains or disappears. If it remains, you are out a little time but now know its probably not a power problem. If it solves the problem, you saved yourself from dealing with clocks for the next two weeks, and then still having to do more troubleshooting because that didn't help. The next easiest is to change your cpu clock divider to something smaller (or none) so you can tweak the baud register more precisely, then attempt to see if using several baud values in a range gets you working at low temps. And so on.

 

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

 

curtvm wrote:
If a better clock ends up being needed, maybe something like a microchip DSC1004AI2-001.0000 can be used, hot glue to board pad side up, hook up a few short wires and have it run the ext clock input. Either use its standby feature or power it from a pin. Turn it on after wake, wait to stabilize, switch clock to ext, send data, turn off, clock back to internal, sleep.

This will require probably to let run internal OSC20M, turn on enable pin for external oscillator and then switch OSC20M to EXTCLK during wakeup. The RTC is then feed by EXTCLK too so wake up counter need to be adjusted accordingly. I am not sure if the Microchip has an application note with sample code for it.

 

Last Edited: Fri. May 7, 2021 - 10:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Received (SRX882 Superheterodyne Receiver) transmitted Manchester code data. On the picture is nibble 0xE, LSB first i.e. 0111

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

>  The RTC is then feed by EXTCLK too so wake up counter need to be adjusted accordingly.

 

The RTC can still run on the internal 32k as it has its own clock select.

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

What is the rx timing when cold vs timing when warm? For ease of testing, get a can of freeze spray to see how far the timing drifts.

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

curtvm wrote:

edit- I would still try the multiple baud value thing, using a clock divider less than /24 to give you more usable baud values. 

I agree. In the post above I gave /10 and /976 as prescale and divider choices, for finer steps in Baud. 

Ideally more than a single divider value will work ok.

If only one divider value works ok, you need to confirm that value is centered on what the receiver tolerates, even if using a crystal clock. 

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

Finally I have found a solution how to measure the baud rate more accurately by modifying the program in the ATtiny202 and sending each 43 seconds 512 sync pulses only. Now I can use Frequency Counter Measurement on the Rigol Oscilloscope which has a precision 6 digit counter and can only be operated with continuous signals under standard conditions.

I have measured frequency at 17°C (63°F) at the 433 MHz receiver, average is 1 025,540 Hz. The program is set to 1 026 BAUD wink.

 

1 025,486
1 025,594
1 025,572
1 025,506

 

I will continue to measure the frequency when the outside temperature will by very low or high.

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

Kevil wrote:

Finally I have found a solution how to measure the baud rate more accurately by modifying the program in the ATtiny202 and sending each 43 seconds 512 sync pulses only. Now I can use Frequency Counter Measurement on the Rigol Oscilloscope which has a precision 6 digit counter and can only be operated with continuous signals under standard conditions.

I have measured frequency at 17°C (63°F) at the 433 MHz receiver, average is 1 025,540 Hz. The program is set to 1 026 BAUD wink.

 

1025,486  1025,594  1025,572 1025,506

 

I will continue to measure the frequency when the outside temperature will by very low or high.

That looks great, you have a 'jitter-span' of about 105ppm or one part in 10,000, and that's about right for a RC oscillator.

Can you measure the Hz, at the same time as it operates, allowing you to catch exact failure points ?

 

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

 

Who-me wrote:

That looks great, you have a 'jitter-span' of about 105ppm or one part in 10,000, and that's about right for a RC oscillator.

Can you measure the Hz, at the same time as it operates, allowing you to catch exact failure points ?

Yes, it's measured on the real ATtiny202 (Internal OSC20MHz) Velcro fixed on the window outside in the Oregon THN132N casing. I receive the data on the 433 MHz Receiver (data are sent over Transmitter).

 

Multiply the frequency by 2 to get BAUD frequency.

 

 

Last Edited: Wed. May 12, 2021 - 09:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That looks great, you have a 'jitter-span' of about 105ppm or one part in 10,000,

Ummmm...not so sure...isn't each of these number the average of many pulses??  If so, the you'd be seeing the variation of the average! 

wonder what you get if you feed in a rock-solid signal from a generator?

I tried it on a Tektronix TDS scope & read 250.013, 250.005, 249.995, 249.989,  250.017 KHZ. On an ovenized freq counter I read 250.0000xx rock steady ...So the scope freq meas has a bit of wiggle

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 wrote:

That looks great, you have a 'jitter-span' of about 105ppm or one part in 10,000,

Ummmm...not so sure...isn't each of these number the average of many pulses??  If so, the you'd be seeing the variation of the average! 

Yes, but that's about right for connecting a RC osc to a good counter

 

avrcandies wrote:

wonder what you get if you feed in a rock-solid signal from a generator?

I tried it on a Tektronix TDS scope & read 250.013, 250.005, 249.995, 249.989,  250.017 KHZ. On an ovenized freq counter I read 250.0000xx rock steady ...So the scope freq meas has a bit of wiggle

Yes, some counters are better than others ;)   and its a trade off of measurement time vs digits returned.

Wonder how good that Rigol counter is ? 

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

Who-me wrote:
Wonder how good that Rigol counter is ? 

 

From an article:

 

My testing suggests the accuracy at ~25C ambient temperature is 1-2ppm.

Last Edited: Wed. May 12, 2021 - 10:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rigol answer:
 

There is no ppm accuracy of the Frequency Counter on the DS1104Z Plus.
 

But the timebase accuracy is ≤ ± 25 ppm based on the datasheet, which is related to the accuracy of the frequency counter.

According to the timebase in your email, the value was 5ms.
 

Therefore, we could have the sampling time = 5ms * 8div = 40ms, the accuracy ≤ 5ms * 8div * ± 25ppm = ± 1us, which means, 0.039999s ≤ the accuracy ≤ 0.040001s.
 

0.039999s ≤ the accuracy ≤ 0.040001s → 24.999375Hz ≤ the accuracy ≤ 25.000625Hz.

However, we only have 6 digits for the frequency counter, the accuracy could not be reflected based on the limited digits.

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

I have fixed the problem as someone suggested here wink.
 

    // If temperature > 31.5°C we need to lower the synchronous BAUD speed to compensate OSC frequency increase
    if (temperature > 315) {
        USART0.BAUD = (uint16_t)USART0_BAUD_RATE(1023) << 6;
    }
    else {
        USART0.BAUD = (uint16_t)USART0_BAUD_RATE(1026) << 6;
    }

I just need to wait for winter to add the additional third condition for temperatures below 5°C .

Pages