detect unknown baudrate

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

Hey guys , I have trouble figuring out the logic for this problem statement:there are 2 atmega328 one transmitting data at an unknown baudrate while the atmega I have to program to detect the unknown baudrate ,I know that if there is baudrate mismatch there should be error but what kind error will be flagged and how will I detect that error Can anyone help me around with logic ,Than you

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

That sounds oddly like a homework problem...but anyway, the hardware USART won't do that for you, you'd have to look at the signals coming in and try to sort it out for yourself.  A common method is to send 0x55 and use the repeating high and low times of each bit to calculate the baud setting.

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

Actually its a homework problem which I need to code but I can't get the logic right,the hardware with unknown baudrate is sending unknown character I thought maybe there would be a framing error if there is a baudrate mismatch between 2 devices ,Thank you

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

Elimathew wrote:

Actually its a homework problem which I need to code but I can't get the logic right,the hardware with unknown baudrate is sending unknown character

Is that really exactly what the question says ?

If you have unknown baudrate is sending unknown character you cannot exactly determine the Baud.

All you can do, is define some limits - lets assume 8N1 serial, and perfect sampling :

 

Shortest possible low time is Start bit alone (sending 0xff) = 1 bit time,

Longest possible low time is sending 0x00 = 9 bit times

 

If you get enough characters, of variable content, you may be able to refine those limits.

 

Of course if someone, decades ago, had given thought to framing Async better, then  you could determine Baud in your case.

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

Yes I am sure the problem statement states that heres the exact problem statement

 

write code to detect the baud rate of incoming data bits. At check out, the TA will connect an atmega328 board to yours via serial port

. The TA’s board will be transmitting an unknown character bit at an unknown

baud rate, unknown parity(either odd or even), and unknown number of stop bits. Transmissions will occur

every 0.1 seconds, and the baud rate will be no faster than 119,600 baud and no slower

than 110 baud. Only "standard" baud rates will be used (110, 150, 300, 600, 1200,

2400, 4800, 9600, 14,400, 19200, 28,800, 31,250, 38,400, 56,000, 57,600, 115,200).

Once the code has detected the baud rate and the character, the LCD should display on

the first line the detected baud; and on the second line, the detected character.

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

Does the "character" bit mean it's limited to printable ASCII characters, or can it be any decimal value from 0-255?

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

First of all, have you done a Google search for "auto-baud rate detection algorithm"?

 

Assuming that the character starts every 0.1 seconds (the Transmit Period),

... The TA is sending only ONE char per Transmit_Period,

...and that you have unlimited number of chars to determine the baud rate.

 

 

 

You still can't tell  0xff at baud 9600 from 0xfe at baud 19200.  They are both single low pulses at 8/n/1 because the LSB comes directly after the start bit.

 

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

Simonetta wrote:

First of all, have you done a Google search for "auto-baud rate detection algorithm"?

 

Assuming that the character starts every 0.1 seconds (the Transmit Period),

... The TA is sending only ONE char per Transmit_Period,

...and that you have unlimited number of chars to determine the baud rate.

 

 

 

You still can't tell  0xff at baud 9600 from 0xfe at baud 19200.  They are both single low pulses at 8/n/1 because the LSB comes directly after the start bit.

 

 

That's true if it can be any binary value, but the way the word "character" is used makes me think there's some implied restrictions.  If it's limited to standard printable characters then there's guaranteed to be at least 2 low periods and you can use the high and low periods to find the least common divisor, from which you can directly compute the baud rate.  The only sequence that causes problems is 0x1C, since it will be 3 periods of equal length with the right party settings, but that falls outside the printable ASCII range.

 

Edit:  Forgot one potential problem, least common denominators of 2 bit periods.  This is a potential twice, with 0x60 and 0x78 in the ASCII range.  A test with the baud rate setting to see if the result is an ASCII character is all that's needed, and if it's not then divide the baud rate by 2.

Last Edited: Tue. Nov 3, 2015 - 11:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

IF the same character is transmitted repeatedly, a 'brute force' method may work. 

 

Say you start with 115200, 8, E, 2. Record the next N characters received. If they match, you pass.

 

If they do not match, twiddle the stop bits, parity, and number of data bits. Anytime two consecutive characters do not match, twiddle something. 

 

Finally, after twiddling with everything else, drop the baud rate to the next lower rate, and repeat twiddling with data bits, parity, and stop bits.

 

Just a gut feeling, no analysis, but I suspect that N = 3 pretty well covers things. However, the characteristics of the students board and teachers board are not mentioned. If they both have crystal controlled clocks, there's  good chance this may work. Otherwise, you're on your own, buddy.

 

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

 

 

Quote:
You still can't tell  0xff at baud 9600 from 0xfe at baud 19200.  They are both single low pulses at 8/n/1 because the LSB comes directly after the start bit.
Or 0xFC at 28800, or 0xF8 at 38400, or 0xE0 at 57600...

 

Also, there's no mention of the number of the frame size.  Is it 8 bits?  That's quite common, but 5, 6, 7, and 9 are also 'typical'.

 

As for parity, are 'even'/'odd' the only option?  What about 'none'?

 

The one thing to your advantage is that, since characters are sent to you no faster than every 0.1 seconds, you don't need to know how many stop bits.  In fact, you >>can't<< determine how many stop bits there are, since a stop bit is indistinguishable from the idle state ('1').

 

Your professor has given you an incomplete problem description.  He should be strung up by his parity bits ;-)

 

"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

A robust method might start by measuring the low-times and high-times, and then attempt to find the common factors.

 

For example, if I send the character 'F', that's 0x46, or 0b01000110.  Sent as 8N1, that would appear as S-0-1-1-0-0-0-1-0-P, where S is the start bit ('0') and P is the stop bit ('1').  So 0-0-1-1-0-0-0-1-0-1.

 

If sent at 9600 baud, each bit time would about 104 us.  I would measure the following:

Bit#   Edge?    us (from falling edge of start bit)
---------------------------------------------------
Start   Yes       0
0        No      
1       Yes     208
1        No
0       Yes     208
0        No
0        No
1       Yes     312
0       Yes     104
Stop    Yes     104

 

So we have three different times:  104, 208, and 312 us.  From this we can determine that the highest common factor is 104.  Any code to do this would have to contend with jitter, so would need to tread (for example) 312 us the same as 313 us.  In other words, you'll need to handle a certain amount of tolerance.

 

The HCF isn't necessarily enough to determine the baud rate, however (see examples given by Simonetta and me), nor will it tell you the frame size, or the parity, or the stop bits (which is actually impossible given the problem description).

"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

I would agree that the assignment is a little ambiguous. OTOH, I guess that the wording implies a printable character 8E1, 8E2, 8O1, 8O2 at standard baud rates. The stop bits are irrelevant for a single byte.

On that basis, you can make pretty good guess with measuring the narrowest and widest "bits".

In the old days, software would look for a carriage-return character. I suppose that an unknown char makes life a lot harder.

David.

Last Edited: Tue. Nov 3, 2015 - 11:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I did some Googling and there were some hits from this site as well as others, but the overall gist of it was basically the same.

 

Most of the 'answers' used a timer to measure the time between edge transitions.  So, without going into a lot of detail, my guess would be to connect the input to a timer to the RXD pin of the AVRs USART and at the beginning of your code disable the usart, and start measuring the time between pulse edges and look for a constant.  Then a math algorithm that calculates the baud rate based on the pulse time and then load the baud rate register with the correct value.  Stop the timer and enable the usart and look for a framing error.  Change teh parity/stop bits for the baud rate you selected and keep watching the flags.  once you have all flags happy(no errors) show the contents of UDR on the screen.

 

If fail, then restart the program and do it over until it all lines up.

 

YMMV.

 

Jim

 

EDIT:

Actually its a homework problem which I need to code

Thank you for being honest with us.smiley

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

Last Edited: Wed. Nov 4, 2015 - 02:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When I need baud rate detection, I rely on a few 'givens':

  • 8N1 or 8N2 (stop bits aren't important anyway)
  • test character is 0x7F or less
  • test characters arrive at a or below some maximum rate

 

With those provisos, the algorithm is simple:

  1. Measure the arrival time of the falling-edge of the start bit
  2. While not 'timed out':
    • Wait for and note the arrival time of any rising edges
  3. Subtract the arrival time of falling edge of the start bit from the arrival time of the last rising edge before timeout.
  4. Divide by 9 to get one bit time
  5. Baud rate is the reciprocal of the bit time

 

The 'timeout' is value is limited by the maximum character arrival rate.

 

That algorithm works because with characters < 0x7F, the MSB bit (transmitted immediately before the '1' stop bit) is always '0', guaranteeing that the last rising edge is the first stop bit.

 

The addition of parity complicates things.

The possibility of characters > 0x7F complicates things.

The possibility of non-8-bit frames complicates things.

The constraint of 'standard baud rates' simplifies things.

"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: Wed. Nov 4, 2015 - 06:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Elimathew wrote:

Yes I am sure the problem statement states that heres the exact problem statement

 

write code to detect the baud rate of incoming data bits. At check out, the TA will connect an atmega328 board to yours via serial port

. The TA’s board will be transmitting an unknown character bit at an unknown

baud rate, unknown parity(either odd or even), and unknown number of stop bits.

 

I wonder if the key is the slightly unusual wording of "an unknown character bit"

 

If they send just one bit low and parity of either even or odd, then that can now narrow down the choices.

a) First Bit low  ==\__.__/===========??====  ie wider pulse 2 bits wide.

b) others          ==\_/=====\_/=======??==== 2 or 3 pulses, and possible a wider last pulse if last bit = parity value.

 

and you can create a decision tree of the possible one,two,three pulses that may be captured.

 

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

1/x of the shortest low pulse give the baudrate 

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

sparrow2 wrote:

1/x of the shortest low pulse give the baudrate 

Yup, correct - but does assume you know one is present & it is isolated from Start or Parity.

That is not the case here.

 

More common is to send a known and fixed 0x55, ("U") where you do know all bits are one bit time.

Streaming a large number of "U" also allows you to test sustained data rates using a frequency counter.

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

I assume that this is a sniffer that can't control anything, but if the data send represent anything meanings full there will somewhere be isolated 0's.