ATtiny202 - External Oscillator Circuit

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

I am having troubles with low outside temperatures which influence the stability of the internal 20 MHz oscillator (/24) for synchronous USART timing (1024 BAUD).

I can't find any ANxxxx suggested external oscillator (TCXO) circuit description for AVR 0-Series ATtiny MCU's which have only one pin available for external oscillator.

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

Kevil wrote:
for synchronous USART timing

Surely, if it's synchronous, then the variations in the speed don't matter?

 

Kevil wrote:
I can't find any ANxxxx suggested external oscillator (TCXO) circuit description for AVR 0-Series ATtiny MCU's which have only one pin available for external oscillator.

Surely, then, it's just a logic-level input?

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Please read the data sheet carefully.
Since the tiny202 does not include an oscillator circuit, it is not possible to connect a "crystal".
What you can do is correct the baud rate using "SIGROW.OSC20ERR5V" or connect a "crystal oscillator" to EXTCLK.

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

If using the uart, adjust the baud register according to temperature. You already have the temperature, now figure out the relationship between temperature to actual baud rate and once known you can adjust the baud register according to the current temperature. I would think that will remain consistent. Its a free fix if it works, and free if it doesn't.

 

You can also check out the OSC20 freq vs temp graph. It looks pretty good over the temp range, and assume you are at the lower voltages which seem to hang around the 20MHz area which helps your calculations. Maybe you have some other problem, but if you measure you will know (or maybe you already have). Having an actual temp vs baud graph of your own would be a good thing to have. The fractional baud rate generator will allow you to tweak the baud register as needed, and you probably have pretty high values with that low baud rate so should have the ability to do fine adjustments.

Last Edited: Tue. May 4, 2021 - 10:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


kabasan wrote:
correct the baud rate using "SIGROW.OSC20ERR5V"

curtvm wrote:
adjust the baud register according to temperature.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't know how low the outside temperature is, but OSC20M fluctuates only about 0.5% from 40°C to -40°C.
Did you calibrate enough at room temperature?
Do you still have problems?

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

kabasan wrote:

Please read the data sheet carefully.
Since the tiny202 does not include an oscillator circuit, it is not possible to connect a "crystal".
What you can do is correct the baud rate using "SIGROW.OSC20ERR5V" or connect a "crystal oscillator" to EXTCLK.

That's what I am looking for, suggested crystal oscillator circuit to connect it to EXTCLK pin.
 

ATtiny202 Data Sheet, pdf page 519:

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

I am using the ATtiny202 as replacement of the Oregon Scientific temperature sensor THN132N placed on a window from outside and sending data to the Oregon Scientific base station. I was told the base station is sensitive to data baud fluctuation max. 20 µs. When the outside temperature is going down the base station won't receive the data.

 

See my another thread below "ATtiny202 - Oregon Scientific temperature sensor replacement"

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

Kevil wrote:
That's what I am looking for, suggested crystal oscillator circuit to connect it to EXTCLK pin.

We would need to know the specifications of the needed circuit or oscillator, as you have not (yet) told us what temperature range you need it to operate at, or answered Andy's question of why in a sync serial comm has a problem at all with a change in clock freq.?

Perhaps something like this will work: https://www.digikey.com/en/produ...

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

ki0bk wrote:
Andy's question of why in a sync serial comm has a problem at all with a change in clock freq.?

Kevil wrote:
I am using the ATtiny202 as replacement of the Oregon Scientific temperature sensor ... I was told the base station is sensitive to data baud fluctuation max. 20 µs

So, presumably, the USART is not actually being used in a synchronous link - just being used to synthesise the bit timings for an async link?

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Even now, I don't know the operating temperature range you want, but if you can't use a resonator, you can use an oscillator.
Probably more accurate than OSC20M.

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

ki0bk wrote:

...what temperature range you need it to operate at, or answered Andy's question of why in a sync serial comm has a problem at all with a change in clock freq.?

Perhaps something like this will work: https://www.digikey.com/en/produ...

 

Jim

I need to operate in 5 to 105 Fahrenheit. Sync serial speed has to comply with expected parameters of the Oregon Scientific base station. It is one way communication only.

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

Looking at:

 

If you pick any one of those Vdd values then the curves themselves are all pretty much identical. There is about a maximum 0.1M variance in about 20M. That is 0.4% potential error (which is presumably +/- 0.2% if you do things right?). What kind of UART is so sensitive that even 0.4% drift is a problem? Usually you can get away with +/-2% or even more before you would usually encounter a problem. So unless things are mis-calibrated so you are already very close to a -2% or +2% bounds of error already then a small extra drift should still be in bounds shouldn't it?

 

While you can add an oscillator (not a crystal) to give a more accurate clock in the first place this just sounds like a calibration thing that needs looking at without the expense of hardware (board space etc).

 

EDIT: 5F is -15C and 105F is 40C so you are only even talking about the "middle bit" of one of those curves anyway - which should further limit the potential drift probably only 0.1% or something?

Last Edited: Tue. May 4, 2021 - 01:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

So, presumably, the USART is not actually being used in a synchronous link - just being used to synthesise the bit timings for an async link?

USART is working in Master SPI communication mode to allow Manchester encoding through CCL, see AN2371 - Manchester Encoder Using USART and CCL on ATtiny817.

 

ATtiny202 signals:
Yellow CLK 1 024 Hz

Cyan synchronous Master SPI USART output

Magenta Manchester code to 433 MHz transmitter (0xC, LSB first)

 


 

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


Kevil wrote:
Manchester Encoder

I thought one of the advantages of Manchester coding was that it allowed clock recovery?

 

Which takes us back to the question: why does it, then, matter what the actual baud rate is?

 

Or is it just that the receiver can only recover the clock over a very narrow range?

 

EDIT

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Tue. May 4, 2021 - 02:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, the receiver can only recover the clock over a very narrow range. I have checked the SIGROW.OSC20ERR3V = 0xFD i.e. -3.

 

The original Oregon THN132N PCB is clocked by an external crystal.

Last Edited: Tue. May 4, 2021 - 03:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thought Auto-Baud | tinyAVR® 0-series though auto-baud won't be a fit for this use case.

edit : oops (post #14)

 

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

Last Edited: Tue. May 4, 2021 - 03:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have tested:

 

Fcpu 20M 24 (prescaler)     1 025,64 1 024,00 Delta %
BAUD BAUD Reg Value *64 Real BAUD Delta    
1 019 409 26 176 1 018,74 -6,90 -5,26 -0,51%
1 020 408 26 112 1 021,24 -4,40 -2,76 -0,27%
1 021 408 26 112 1 021,24 -4,40 -2,76 -0,27%
1 022 408 26 112 1 021,24 -4,40 -2,76 -0,27%
1 023 407 26 048 1 023,75 -1,89 -0,25 -0,02%
1 024 407 26 048 1 023,75 -1,89 -0,25 -0,02%
1 025 406 25 984 1 026,27 0,63 2,27 0,22%
1 026 406 25 984 1 026,27 0,63 2,27 0,22%
1 027 406 25 984 1 026,27 0,63 2,27 0,22%
1 028 405 25 920 1 028,81 3,17 4,81 0,47%
1 029 405 25 920 1 028,81 3,17 4,81 0,47%
1 030 404 25 856 1 031,35 5,71 7,35 0,72%
1 031 404 25 856 1 031,35 5,71 7,35 0,72%
1 032 404 25 856 1 031,35 5,71 7,35 0,72%

 

int8_t USART_0_init()
{

	USART0.BAUD = (uint16_t)USART0_BAUD_RATE(1026) << 6; /* set baud rate register */

    USART0.CTRLB |= USART_TXEN_bm;
    USART0.CTRLC = USART_CMODE1_bm | USART_CMODE0_bm | USART_UDORD_bm | USART_UCPHA_bm;

 

#define USART0_BAUD_RATE(BAUD_RATE) ((float)(833333 / (2 * (float)BAUD_RATE)) + 0.5)

 

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

Kevil wrote:
I can't find any ANxxxx suggested external oscillator (TCXO) circuit description for AVR 0-Series ATtiny MCU's which have only one pin available for external oscillator.
A clock generator has a crystal oscillator and a PLL; current consumption is 1 to 4 mA typical.

Other MHz oscillators consume 5mA plus or minus.

Both have an enable to greatly reduce current consumption; AVRxt are frequency agile.

AVR DD will have a crystal oscillator in SOIC-14.

 

PL611s-18 - Clock and Timing - Clock Generation via Low Power Clock Generation Products - Microchip Technology Inc via Clock and Timing | Microchip Technology

AVR DD Product Brief

 

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

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

 to 433 MHz transmitter

Perhaps more likely, given the baud rate analysis above, than a baud rate error is that the (cheap) 433 MHz transmitter's frequency drifts with the temperature.

 

If your external sensor has Mains power, then add an NFet and a power resistor to the circuit, within the enclosure.

You can then then measure the outside temperature and turn on your heater, (the power resistor), to warm up the inside of the enclosure.

This will keep the transmitter happy.

 

If the remote is battery powered then this option won't work.

 

JC 

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

Another option other than making a baud register correction for current temp (by testing), is to simply pick out the baud register range you know you will work and simply send out the temperature data for each of those baud values. So if it seems that the baud register range is 5 values depending on temperature or whatever, you just send out 5 times changing baud register each time, and at least one of those will be received.

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

curtvm wrote:

That's a good interesting idea. Maybe I will test it.

Last Edited: Tue. May 4, 2021 - 06:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The PCB. U2 is the ATtiny202, U1 the Boost Converter 1.5 to 3.3 V MCP16251. R1 label should be more to the right, below the resistor below U1. Sorry for my soldering, I am not so experienced yet.

 

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

you just send out 5 times changing baud register each time, and at least one of those will be received.

Interesting idea, but remember, that the other 4 will likely produce some garbage characters or strings of complete junk...so effective string rejection at the rcv end is a must & some error checking should definitely be included...however, are you changing code at the "base station"?  Maybe no chance to do so.

 

If you have means to rcv a message at the AVR (like sending it "QQQQ"), you can use autobaud methods to adjust the registers accordingly (but doesn't seem like you have this option).

 

some of the following info might prove useful (or not), to tell what the sensor is doing in terms of moving data (however, it could just be some hacker's interpretation of what appears to be happening, rather than an official Oregon Sci protocol)

 

https://www.disk91.com/2013/tech...

 

 

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

Last Edited: Tue. May 4, 2021 - 07:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
... this just sounds like a calibration thing that needs looking at without the expense of hardware (board space etc).
Atmel-ICE can generate a clock signal; required temperature range is freezer to heating pad.

 

Measuring the Calibration Clock Frequency | XMEGA Internal RC Oscillator Calibration

...

The frequency of the calibration clock signal should be in the 32 kHz range.

...

AN2644 XMEGA Internal RC Oscillator Calibration

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

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

>Interesting idea, but remember, that the other 4 will likely produce some garbage characters 

 

If I recall, the protocol in use for this thing has a preamble and a checksum of some sort, so should be fine I would think.

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

Yes, you are right. The data includes checksum and polynomial CRC. See Oregon Scientific RF Protocol Description.

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

It's AA 1.5V battery powered. 2x 162.8ms@20mA data each 43 seconds, sleep 980µA (incl. 433 MHz transmitter).

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

Kevil wrote:

I am having troubles with low outside temperatures which influence the stability of the internal 20 MHz oscillator (/24) for synchronous USART timing (1024 BAUD).

 

What troubles exactly ?

Are you saying in #18 that /406 is ok but /405 or  /407 fail ? 

 

Wow. That's a 0.246% step size, which I'd call baud-paranoid.

 

That tolerance band is way less than the Osc trim step size, so even RC calibrate will not be good enough.

 

It also gives you very little system trim margin, as you have to hope the other end properly centres on the 406 value.  Is the very-fussy other end, Crystal controlled ? 

 

If you really do need that precision, you likely will need an external CMOS crystal oscillator, those are easy enough to find.

±50 ppm are very common and ±10 ppm can be found with a little effort.

 

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

I am sending data (outside temperature) by ATtiny202 and 433 MHz Transmitter to the Oregon Scientifics base station.

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

Yes, with /406 it works almost perfectly. I will try to switch the internal OSC to 16M (from 20m) with the same prescaler 24 which gives me /325 and 0 Delta for 1025.64 Hz.

 

The original Oregon THN132N PCB is using crystal oscillator.

 

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

Kevil wrote:
The original Oregon THN132N PCB is using crystal oscillator.
32KHz?  If yes there are 32KHz TCXO that are very low current.

Model TT32 HCMOS TCXOs - CTS Electronic Components | Mouser

TG-3541CE (TCXO) Crystal Oscillators - Epson | Mouser

 

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

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

Not sure why you'd mess around with 20 gyrations of madness when a simple & cheap solution is a 10 cent crystal in your system.  Very accurate & cheap & stable.  Might take a ms to stabilize at power--so do watch that. 

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:

Not sure why you'd mess around with 20 gyrations of madness when a simple & cheap solution is a 10 cent crystal in your system....

 

A crystal does not work too well with the #1 :  which have only one pin available for external oscillator.

Thus an external CMOS oscillator is needed, if only one pin exists.

 

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

Kevil wrote:

The original Oregon THN132N PCB is clocked by an external crystal.

 

Do you have a working original unit, you can carefully check the exact baud rate on ? 

If the overall system, is very baud rate paranoid, you may want to target the actual value, rather than a nominal '1024' paper spec.

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

Kevil wrote:

The original Oregon THN132N PCB is using crystal oscillator.

 

Strictly technically, that's a 'crystal', not a 'crystal oscillator'.  Yes, it's a crystal, and yes, it oscillates, but not by itself.  It needs a crystal driver (which your Tiny202 doesn't seem to have).

 

It's like the crystal is an auto engine, and a 'crystal oscillator' is the whole automobile (driver included).  There is an important (if somewhat pedantic) distinction to be made here, but if you're off to get the groceries it's good to be careful of the difference.  Hope that helps some.  S.

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

A crystal does not work too well with the #1 :  which have only one pin available for external oscillator.

Ummmm....just pick an AVR that has an XTAL connection, that would be the first step (or use an osc & increased cost)

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

Last Edited: Wed. May 5, 2021 - 05:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

A crystal does not work too well with the #1 :  which have only one pin available for external oscillator.

Ummmm....just pick an AVR that has an XTAL connection, that would be the first step (or use an osc & increased cost)

Sure, if the design does not already have a PCB done....

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

The big assumption here is that the OP's frequency measurements are accurate. They are, after all, using a scope to measure them and the display is only showing two decimal places.

#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

That's why I need to recover the CLK to be able to measure the CLK frequency with higher accuracy on Rigol Oscilloscope by counter function.

 

See AN1470 Manchester Decoder Using the CLC and NCO.

 

Any suggestion to simple CLK recovery circuit would be appreciated. Maybe I can use another ATtiny202 for clock recovery - Configurable Custom Logic (CCL).

Last Edited: Wed. May 5, 2021 - 07:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's AA 1.5V battery powered.

Note that a typical problem with external oscillators is that they are relatively power-hungry things, compared to an AVR. A couple of 10s of mA is not unusual, and it won't turn off during CPU "sleep" modes.

 

 

Last Edited: Wed. May 5, 2021 - 08:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Kevil wrote:

That's why I need to recover the CLK to be able to measure the CLK frequency with higher accuracy on Rigol Oscilloscope by counter function.

 

You don't need to do that. Take a step back and measure the actual frequency of the chip's oscillator over the working temperature range. Write a simple bit of code that toggles an output pins as fast as possible and measure the frequency of that. You will now know what the real temperature drift in frequency is.

#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

westfw wrote:
a typical problem with external oscillators is that they are relatively power-hungry things

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

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good suggestion although not easy to route wires from outside of the window wink.

 

Another "wireless" option would be to buy the AVR128DA48 Curiosity Nano Development Board and run the Manchester Decoder.

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

not easy to route wires from outside of the window

 

Go on - you do this testing on your bench!

 

Use an ice pack, or pop it in the fridge to check low-temperature operation ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kevil wrote:

Good suggestion although not easy to route wires from outside of the window.

 

LED and a photodiode. A cheap IR LED will be good out to 10MHz or so, a photodiode will not even break a sweat at that rate.

#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

Another option is to up your clock speed so your uart baud register has more values to work with. If you only have 1 value that works when you are /24, then maybe if you go to something like /1,/2,/4 while you transmit you now have more values that will work, and can try them all as mentioned earlier so you get a 'good' one no matter the temp.

 

edit- something else I probably keep forgetting is the code in #18 reminds me your baud rate (spi mode) is no longer using the fractional capabilities which is why the fine tuning ability is not available like in the uart fractional modes. 

 

 

Last Edited: Wed. May 5, 2021 - 11:25 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:

It's AA 1.5V battery powered.

Note that a typical problem with external oscillators is that they are relatively power-hungry things, compared to an AVR. A couple of 10s of mA is not unusual, and it won't turn off during CPU "sleep" modes.

Good point, but many oscillators have an enable pin, or you can simply power thru a port pin.

Allow a startup time, before switching to external clock mode.

 

You could look at these, I've tested this family at 1.5mA (CL=0) and ~ 100us startup time.

lcsc C669067 Yangxing Tech OT252020MJBA4SL 20MHz 10ppm 1.8V~3.3V 4mA SMD-2520-4P
lcsc C669079 Yangxing Tech OT201620MJBA4SL 20MHz 10ppm 1.8V~3.3V 4mA SMD-2016-4P
 

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

Brian Fairchild wrote:

The big assumption here is that the OP's frequency measurements are accurate. They are, after all, using a scope to measure them and the display is only showing two decimal places.

The time display is 4 digits, and you can zoom on any decent storage scope, to resolve edges to tighter values.

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

You may be able to zoom to "tighter values" but that does not necessarily mean more accuracy in the absolute sense. It might, but that varies from one model to the next.

 

Jim Wagner

 

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

 

 

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

ka7ehk wrote:

You may be able to zoom to "tighter values" but that does not necessarily mean more accuracy in the absolute sense. It might, but that varies from one model to the next.

 

Perhaps, but easily checked.

All digital  scopes I've used have a crystal master timebase and the sample rates are digital and very precise.

The screen display is usually what limits the 'visual precision', but the underlying precision is as good as the sample rate, which is usually memory-depth related.  

  • 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