ATTiny816 UART 250kbps accuracy

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

My old circuits use ATmega88 , 16MHz crystall, UART 250kbps, 8bit , 2 stop, no parity, both RX and TX

 

ATtiny816 has inetrnal 16Mhz and 20MHz RC factory calibrated with +-2% accuracy in 0-70°C range

attracts me quit from ATmega88 and get rid of crystall

 

my previous attempts to use internal 8Mhz RC of ATmega88 was unsuccessfull,

with 2% tolerance 250kbps will slow down to 245kbps and rise up to 255kbps ,cause bit spaces interfere eachother at last bits of the frame

according to datasheet and sampling 8,9,10 slices out of 16 slices of 1 bit, it seems possible,

 

I appreciate everyone share experineces

 

 

 

Majid

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

250 kbaud. Is that for DMX?

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "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." - Heater's ex-boss

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

So you've also posted this as a side-track in the other thread anyhow: https://www.avrfreaks.net/comment...

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

Brian Fairchild wrote:
250 kbaud. Is that for DMX?

Yes, it is

Majid

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

Lot's of fellow freaks have gotten into trouble with RC oscillator / uart combination.

Personally I've never seen a reason to omit a 20 cent crystal.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

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

It's not just Freaks - pretty much universal to any microcontroller!

 

Personally I've never seen a reason to omit a 20 cent crystal

indeed! 

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

mostly because of save space and reduce component quantity 1 crystall + 2 caps, less component less pick and place

Majid

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

if both ends are real uart's there is no problems in +- 2% (ever).

 

with 2% tolerance 250kbps will slow down to 245kbps and rise up to 255kbps ,cause bit spaces interfere eachother at last bits of the frame

Will not happen. 

 

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

good point,

maybe the worst combination is one with +2% ther other -2% and vice versa

seems rare condition , but must be considered

Majid

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

Over what temperature range will your equipment need to operate? 

If always in-doors in normal room conditions, it "may" work, over extend temperature range, may not with out a xtal!

 

Jim  I have no experience with the new xtiny's!

 

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

see #1 

2% 0-70C

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

As your DMX signal is always present why not use it to run-time calibrate your controller?

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "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." - Heater's ex-boss

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

ki0bk wrote:
Over what temperature range will your equipment need to operate? 

İndoor, 0-50°c

Majid

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

Brian Fairchild wrote:
use it to run-time calibrate your controller

Good idea,
first data byte always 0,
I will do if needed

Majid

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

ki0bk wrote:
I have no experience with the new xtiny's!

Me too,
I am evaluating suggestions then decide to invest time and start
Attiny816 rather new, with amazing features

Majid

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

first data byte always 0,

Until it isn't.  If you try to run your DMX receiver on an RDM universe (or a DMX universe which uses vendor-specific start codes for things like dimmer pack configuration), you may get a nasty surprise.

 

Spaces will always (except for the break) come in bit widths of 1-to-9 bits.  Better to periodically time a range of spaces in a frame (even all of them, but excluding the break), and bin them into 1-bit, 2-bit, etc bins.  At +/-3%, you'll never confuse bins.  Then, compute the average length of each bin, and then the average length of one bit.

 

At 16 MHz, a bit width is 64 cycles.  Fairly easy to use input capture to time spaces, but you may need to resort to assembly instead of C for the timing-critical parts.  If the average is less than 64 bits, your clock is slower than the lighting desk.  If the average is more than 64 bits, your clock is faster than the lighting desk.  Tweak the oscillator calibration accordingly to target an exactly 64-cycle average bit length.

 

EDIT: You can have as many as 5 spaces per slot (start bit, and data bits 1, 3, 5, and 7 as '0', for a value of 0x55), or as few as 1 space per slot (start bit followed by 8 '0' data bits).  With a 512-address universe, plus the start code, you can have as many as 2,565 spaces, or as few as 513.  With each 1-bit space having a nominal width of 64 cycles, the cumulative count in bin #1 could reach as high as 164,160, requiring a 3-byte accumulator.  At the other end, each 9-bit space will have a nominal width of 576 cycles, so the cumulative count in bin #9 could reach as high as 295,488, so each bin will require a 3-byte accumulator.  You'd also need to maintain a 2-byte counter for each bin.  Total memory cost would be 45 bytes for the bin states.  Mind you, this is if you decide to profile an entire frame.  You could limit your captures to just a handful of slots and that would likely be enough.

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Fri. Jan 5, 2018 - 11:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:
If you try to run your DMX receiver on an RDM universe (or a DMX universe which uses vendor-specific start codes for things like dimmer pack configuration), you may get a nasty surprise

I am aware of RDM, after break ignor data not starting with 0

joeymorin wrote:
Better to periodically time a range of spaces in a frame...

I got your idea, a little complex! But possible

No problem with asm if needed as you mentioned in time critical codes

Majid

Last Edited: Fri. Jan 5, 2018 - 11:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks everbody for idea and points
Very valuable for me : )

Majid

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

So you want to save $0.25 for a Crystal and two caps. To connect your device to a DMX network whose components(lights, dimmers, etc) cost thousands each?
Makes perfect sense.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

1. #7

2.Why not to save 0.25$ ?

Majid

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

Because of the potential failure of the device to communicate during run time. Then the headache explaining to an irate customer why your device failed, then the embarrassment , and loss of product confidence all for a $0.25 savings and the concern over machine pick and place. This results in loss of sales, which is higher than the $0.25 savings.

Yep. Good idea.

One thing I have learned with communications is that as the speed goes up, the tolerance goes down...this tolerance I also affected by noise introduced into the cable if it is unshielded, or the shield is compromised.

Your product, your reputation. Is it worth the hit over $0.25?
Your call.
Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

jgmdesign wrote:
Your product, your reputation. Is it worth the hit over $0.25?

...in response to ...

m.majid wrote:
2.Why not to save 0.25$ ?

 

Now, in #19 jgm mentioned the design/app criteria a bit.  Indeed, that is what I'll say in response:  As it [almost?] always does, "It depends".

 

Is OP making a handful of these devices, for personal use?  Then even with "free" time OP may be way beyond the payback.  [I realize this is pre-build discussion]

 

Now, I have some production apps over the years where we have chosen internal oscillator, though it has a UART link.  With datasheet examination and experimentation, the internal oscillator is found to stay pretty flat at constant supplyV and temperature.  [YMMV]  The comms link, in all likelihood, will be used in a benign [temperature] environment.  So we do a one-time cal at ISP time.  No hit to our product reputation over the years of production. [n.b. the driver behind this is the much faster wakeup time from powerdonw; a crystal takes some milliseconds and also draws some power]

 

It depends.  One size does not fit all.  In general, I agree with the suggestion to use an accurate clock source when warranted.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Hmmmmm, ok I'll back off a bit and ask this:

 

m.majid:

What does your black box interface to? 

Is it up on a light bar on a stage?

Is it at a control console? 

Could it be anywhere? 

Is this device going to be installed in a permanent setting or portable?

 

I suppose my having a better understanding of the final application would rationalize your idea.

 

Cheers

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

mostly because of save space and reduce component quantity 1 crystall + 2 caps, less component less pick and place

Use a ceramic resonator, they are a three-terminal device with integrated caps.  Single part to pick and place.  That's what the UNO R3 uses.  Specifically, the part number is CSTCE16M0V53-R0.

 

Digikey lists it at $0.26858 for qty >= 1000.  Board space used is minimal, overall SMD package/footprint is 3.2mm L x 1.3mm W x 0.9mm H.  Both SMD and PTH available.  Tolerance of that particular part is +/-0.5%, sufficient for comms including DMX.

 

There are over 1600 parts in the DigiKey catalog, many less expensive, but about the cheapest (from them) suitable SMD part will be about $0.22/qty1000.  PTH is cheaper still.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

jgmdesign wrote:
Because of the potential failure of the device to communicate during run time

This is exactly what I concern, please focus on this let me understand what I miss,
2% SEEMS readonable for 250kbps

My reason is #7, I welcome saving $0.25 if THERE IS NO RISK

What is this potential failure?

jgmdesign wrote:
One thing I have learned with communications is that as the speed goes up, the tolerance goes down...

is %2 ok for 250kb?
İf not what is safe tolerance for 250kb

jgmdesign wrote:
Your product, your reputation. Is it worth the hit over $0.25?

Ofcourse not, I am not hitting $0.25 again #7

theusch wrote:
Then even with "free" time OP may be way beyond the payback.  [I realize this is pre-build discussion]

İ didnt got what you mean! Please use simple english!

theusch wrote:
Now, I have some production apps over the years...

Thank u for sharing your experience

Majid

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

jgmdesign wrote:
I suppose my having a better understanding of the final application would rationalize your idea

Well led fixture mainly indoor, maybe lots of them connected serially each other transferring data to each other
First device get data from desk, ohters from eachother

Majid

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

joeymorin wrote:
Use a ceramic resonator...

Thanks for sharing seems compact size, I will consider

Majid

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

m.majid wrote:
is %2 ok for 250kb? İf not what is safe tolerance for 250kb

I'm wondering how much time you have spent researching this AVR clock issue before the posted topics here?  Did you determine why you were previously "unsuccessful"? How far off was the particular failing sample from nominal?  IIRC that model line's clock should be fairly stable at steady temperature.  Did you do a one-time or continuous cal using some reference source?  [Note that while "autobauding" is generally easier with a fixed trigger byte value, surely one could find a bit or a few in the data stream to help tune.]

 

In any case, re the 2%, have you looked in the [wait for it] datasheet?  In this case, the Asynchronous Operational Range section of the USART chapter.  There is discussion and formulas and tables.

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

First device get data from desk, ohters from eachother

That breaks the DMX standard.

 

Yes, devices daisy-chain via the 5-pin XLR connectors, but this is a 'pass-thru' arrangement.  That is, the DMX-IN and DMX-OUT connectors on any fixture/dimmer/etc are electrically connected.  In essence, the 'OUT' is really a 'THRU', just like a MIDI-THRU.

 

You should not be reading the DMX signal on the DMX-IN connector and then pushing out a duplicate on the DMX-OUT connector with the microcontroller's USART TX.  If this is what you're doing, then it means that a failure in one device, or even if it is just powered off, means all down-stream devices lose comms.  I have seen some commercial DMX receivers (in this case, they were colour scrollers for conventional instruments) which behaved this way.  Took forever to diagnose the problem.

 

You will only need the RX on each device, no TX (unless implementing RDM).

 

The only consequence of a bad comms link (either due to clock issues or otherwise) should be constrained to the device in question, and not transmitted to downstream devices.

 

is %2 ok for 250kb?

In general, yes.  the 2% figure isn't tied to the baud rate, but to the frame size.  DMX is 8N2, so the frame size is 10 bits (11 if you count the 2nd stop bit, but that is ignored by the USART RX on the AVR).

 

It boils down to where the RX takes a samples in each bit.  The RX takes three samples of each bit and uses a majority vote to determine the bit value.  Ideally, the samples are taken in the middle of the bit.  With normal-speed mode (which you should use), there are 16 samples for each bit, but only the middle 3 (samples 8, 9, and 10) are considered in the majority vote.  With mismatched baud rates, the position of those three samples will drift from bit to bit as the frame is received.

 

For example, with a 10-bit frame (1 start, two data, 1 stop), normal mode (16 samples per bit) and precisely 250kbps, samples are taken every 250 ns.  The relevant samples are taken at:

 

  µs
bit0  
sample 8 1.875
sample 9 2.125
sample 10 2.375
bit1  
sample 8 5.875
sample 9 6.125
sample 10 6.375
bit2  
sample 8 9.875
sample 9 10.125
sample 10 10.375
bit3  
sample 8 13.875
sample 9 14.125
sample 10 14.375
bit4  
sample 8 17.875
sample 9 18.125
sample 10 18.375
bit5  
sample 8 21.875
sample 9 22.125
sample 10 22.375
bit6  
sample 8 25.875
sample 9 26.125
sample 10 26.375
bit7  
sample 8 29.875
sample 9 30.125
sample 10 30.375
bit8  
sample 8 33.875
sample 9 34.125
sample 10 34.375
bit9  
sample 8 37.875
sample 9 38.125
sample 10 38.375

 

In order to avoid bit errors, you want to make sure that any baud mismatch is not so great the the samples for the last bit drift beyond the beginning or the end of the real bit.

 

In the case of the above, you want to ensure that the first relevant sample (sample 8) of the last bit (bit 9) is not taken before the beginning of the transmitted bit.  That point is 37.875 us after the onset of the start bit, and there are 9 bits which pass before the onset of the last bit, so the maximum bit width from the sender is 37.875/9 = 4.20833 us, for a minimum baud rate of 237.623kbps, or a mismatch of -4.95%.

 

At the other extreme, you want to ensure that the last relevant sample (sample 10) of the last bit (bit 9) is not taken after the end of the transmitted bit.  That point is 38.375 us after the onset of the start bit, and there are 10 bits will will have passed before the trailing end of the last bit, so the minimum bit width from the sender is 38.375/10 = 3.8375 us, for a maximum baud rate of 260.586kbps, or +4.23%.

 

You'll note that this is much greater than the +/-2% generally quoted.  The extra margin is recommended because the above figures are absolute maximums which assume otherwise absolutely perfect conditions (clean bit edges, no jitter, no noise, etc.).

 

AVR datasheets have a table:

Note that the figures agree closely with my calculations above.  The difference is likely due to the actual placement of the samples.

 

Bottom line for you is that +/-2% >>may<< be OK.  It may not be.  Much depends on the environment.  The +/-2% is a >>combined<< error between TX and RX.  If the TX is +0.2%, and your RX is -2%, then the combined error is about -2.2%, which is outside the recommended margin.  On a short, clean run of DMX you'll likely be fine.  However, with longer runs you may get into trouble as the signal edges will smear and noise will be greater.  If there are great many other fixtures in the run, then each station will degrade the signal somewhat with small signal reflections with each edge.  If multiple cables are involved, any dirt or corrosion on the pins (quite common in a real-world installation) will create additional noise and smear.  If the run lacks a terminator, then significant signal reflection will occur, and it will start to be a problem anywhere over about 500-1500 foot cable runs.

 

For me, the bottom line is "do I want my gear to be the first to fail in a given installation?"  The answer is of course "No!".

 

 

 

 

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sat. Jan 6, 2018 - 06:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice post Joey!

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

I should say I didnt dare to calibrate İnternal RC of ATmega88 5years ago!
I chose simple way : Crystal and stay away from RC and calibration so I did not search to find solution

Now feel more confident,
And there are some requirements to design some compact PCBs, I looked to tiny series and find Attiny816, amazed by features such as " factory stored calibration" and also price $0,6

Besides I thaught its time to catch up with some new MCUs,
Attiny816 seems satisfies my requirements

%2 is in datasheet just for factory stored calibration both 16 and 20MHz
I used stored calibrated 20MHz and activated Tx 250kb and did a rough test,
cooled down to - 20°C and warm up to 120°C measured pulse width 4.01us @-20, 3.96us@120

Seems possible, but before go further I need to be sure I am in right way,

Majid

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

m.majid wrote:

... I looked to tiny series and find Attiny816, amazed by features such as " factory stored calibration" and also price $0,6

Besides I thaught its time to catch up with some new MCUs,
Attiny816 seems satisfies my requirements...

Then you will find this thread to be of interest;  https://www.avrfreaks.net/forum/a...

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Sat. Jan 6, 2018 - 07:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for complete post

I am aware of disadvantage of dasy-chain
Requirements allow it and accept consequences

joeymorin wrote:
In order to avoid bit errors, you want to make sure that any baud mismatch is not so great the the samples for the last bit drift beyond the beginning or the end of the real bit.

drift caused by %2 tolerance doesnt interfere 8.9.10 sampling, I will recalculate for worst combinatin Tx +2%, Rx - 2% to see where exactly is...
I will here

I will consider rest of your post in details

Majid

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

I am aware of disadvantage of dasy-chain
Requirements allow it and accept consequences

I think you've misunderstood me, or you've misunderstood the DMX standard.  Re-broadcast of the incoming stream does not comply with the standard.  The 'OUT' connector on your device must be electrically in parallel with the 'IN' connector.  Your device need not, and must not, re-broadcast the data stream.  Doing so makes it a repeater rather than a passive node.  I strongly recommend against this.  Any fault in your device will affect all downstream devices.

 

drift caused by %2 tolerance doesnt interfere 8.9.10 sampling, I will recalculate for worst combinatin Tx +2%, Rx - 2% to see where exactly is...

Don't forget that figure is meant to accommodate real-world conditions.  I've shown you the calculations.  What you can't calculate is the degree of edge smear, noise, and signal reflections you'll have to contend with on a real installation.  Don't mess around.  Use a resonator or a crystal, or calibrate in software to make sure you are as accurate as you can be.  When calibrating, you >>must<< take an average of several spaces and/or marks, otherwise you're likely to arrive at an inaccurate measure of the real speed due to the aforementioned effects of edge smear, noise, and signal reflections.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

ATtiny816 max recommended receive error for 8 bit  is  +4.58/-4.54 (Table 24-4)

 

I calculated receive error for %2 tolrance of clock as below:

 

also examined sampling: (green color 8.9.10 samples)

 

it seems for clean signals it will work fine and not be affected by temperature change.

 

joeymorin wrote:
However, with longer runs you may get into trouble as the signal edges will smear and noise will be greater.  If there are great many other fixtures in the run, then each station will degrade the signal somewhat with small signal reflections with each edge
 

for noise spikes on signal, I think no difference between crystal and %2 calibrated RC , it may occur every point of pulse

but "signal reflection" affect edge of pulse more than middle, it most likely affect sampling on last bits, I agree

 

I got my respose and convinced not to rely on %2 calibrated RC for DMX !

It may be used with awareness of not robust against signal reflection.

 

 

 

 

Majid

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

I guess it's ok if you use :

 

• SIGROW.OSC16ERR3V is the frequency error from 16MHz measured at 3V

• SIGROW.OSC16ERR5V is the frequency error from 16MHz measured at 5V

• SIGROW.OSC20ERR3V is the frequency error from 20MHz measured at 3V

• SIGROW.OSC20ERR5V is the frequency error from 20MHz measured at 5V

Then you can get a better baud rate than the actual clk speed!  

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

for noise spikes on signal, I think no difference between crystal and %2 calibrated RC , it may occur every point of pulse

There can be many sources of noise, not all of which will result in spikes.  Constant noise, both broadband and narrow band will have a negative effect which will only be worsened by a baud rate mismatch.  Remember, the USART employs a majority vote to arrive at a bit value.  More noise, more likely the vote will be incorrect.  If a vote is taken near or spanning a bit boundary, the more likely the vote will be incorrect.  The greater the edge smearing, the more likely the vote will be incorrect.

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]