3300 baud +-

Hi, so I am trying to speak in serial to peripheral sensors that take somewhere in the neighborhood of 3300 baud. Unfortunately this falls in between standard arduino baud rates. The signals will just be short 8 bit hex if that makes a difference. Anyway, how do I get 3300 baud out of an arduino? Is there some sort if a baud shifting dip?

You should be able to program the baudrate by setting the values of the appropriate registers. You need to study the Atmel datasheet for your MCU which explains this in all its gory detail. Whether 3300 baud is possible I don't know.

You might also be interested in this Thread as a basis for writing your own software version.

I'm very surprised that sensors use non-standard baud rates - are you sure?

And I'm not sure what are the implications of "short 8 bit hex" - is it standard serial data, or not?

...R

AFAIK the hardware serial supports any baudrate and calculates the register values.

What version of the IDE do you use? Do you have a datasheet of the peripheral sensors? please post a link!

Hey guys, sorry for the delay. It was a busy week. So the sensors are automotive parking sensors which means there really isn't a datasheet available for them. There is a pretty good instruct able on hacking the Bosch sensors, but nothing on the other major brand. When I listen in on the parking module speaking to the sensors, 3300 baud is what it takes for the sales to make sense of my samples. The reason I want to make this work with software serial, is because I need to talk to four separate sensors.

The Arduino Mega have 4 hardware serial ports, so you could use this.

If you really want to use SoftwareSerial, I believe you can use any bauds, as long as you add it to a table in Arduino\hardware\arduino\avr\libraries\SoftwareSerial\SoftwareSerial.cpp

  //  baud    rxcenter   rxintra    rxstop    tx
  ...
  { 9600,     114,       236,       236,      233,   },
  { 4800,     233,       474,       474,      471,   },
  { 2400,     471,       950,       950,      947,   },
  { 1200,     947,       1902,      1902,     1899,  },
  ...

This is an extract of the table for 16MHz processors.

Based on this formula (which is inaccurate when compared to the values in the table, but still is helpful):

rxstop = 16000000L/(7 * baudrate) - 2; rxintra = rxstop; tx = rxstop - 4; rxcenter = rxstop/2 - 5;

You could try to add this line to the table:

{ 3300, 341, 690, 690, 687 }

You may need to tweak the values a little.

computertron: When I listen in on the parking module speaking to the sensors, 3300 baud is what it takes for the sales to make sense of my samples.

Can you explain in detail what you mean by this and how you do it?

...R

No electronics designer in the world would use a baudrate that is not a standard baudrate. At least, not a good designer :P Are you sure that you measured the baudrate correctly ? The baudrate 38400 is very common. It is the best baudrate for the Arduino, since it has the least percentage inaccuracy with 16MHz and 8MHz crystal.

It think it is also possible to change the divider registers after calling Serial.begin().

@guix, I spent some time reading over the thread containing those tables and while implementing the table is a little over my head at the moment, I understand the concept and need to start really reading up on this sort of thing.

@robin2, that is actually a splendidly specific sentence that has been ruined by autocorrect. Replace "sales" with salea and it should make more sense. The parking system consists of one microcontroller running eight sensors on separate asynch channels. Based on the instruct able for the Bosch sensors, I learned that these sensors require ping and listen commands that will be distinct. So with the system running, I hooked up a salea logic 4 logic analyzer to 4 channels and tried to make sense of the data capture.

8bit 3300 baud matches the data perfectly with no errors. I thought perhaps I could fake it by translating the 4 commands I was able to see into 24bit 9600, but that actually generates a few errors when I plug that into the logic analyzer.

It may also be important to state that serial is only necessary for the tx channels. The echoes for these ultrasonic sensors are a direct representation of echoes received, and you have to time that against the last ping command for distance data.

No start or stop bits? The SoftwareSerial code will send start/stop bits.

Do you just want to send 8-bits of data to each of the four devices at about the same time?

computertron: So with the system running, I hooked up a salea logic 4 logic analyzer to 4 channels and tried to make sense of the data capture.

8bit 3300 baud matches the data perfectly with no errors. I thought perhaps I could fake it by translating the 4 commands I was able to see into 24bit 9600, but that actually generates a few errors when I plug that into the logic analyzer.

I can't help feeling you are barking up the wrong tree - trying to make some proprietary system fit into the standard serial format.

Can you post some pictures from your logic analyzer?

At 3.3k bits per second the Arduino would be well able to interpret the data. Have you looked at the Thread I linked to in Reply #1 as a basis for writing your own code to interpret the data.

You may also get some useful stuff from this long Thread which is also about interpreting automotive data.

...R

Looks like 3300 baud rate is possible (with 0.0% error). Scroll down to the 16MHz table.

http://www.wormfood.net/avrbaudcalc.php?postbitrate=3300&postclock=16&bit_rate_table=1

dlloyd: Looks like 3300 baud rate is possible (with 0.0% error). Scroll down to the 16MHz table.

I can't help feeing that if 3300 baud would solve the problem the OP would not be asking questions here. I suspect the problem is more complex.

...R

I can't help feeing that if 3300 baud would solve the problem the OP would not be asking questions here. I suspect the problem is more complex.

I'm referring to hardware serial. This will involve setting UBRR to 302.

Reference: Atmega328P Table 19-12, page 203

I can't see where this has been tested. No doubt, hardware serial inherently will have fewer issues than software serial.

Does this set UBRR to 302 on the Atmega328P? (I'm only familiar with the Due).

Serial1.begin(3300);

I've investigated any baud rate with SWSerial in the past here - http://forum.arduino.cc/index.php?topic=138497.0 -

In practice any baudrate above 70~80Kbit fails - also discussed in that thread, however I did not investigate the low end of baudrates.

dlloyd: I'm referring to hardware serial. This will involve setting UBRR to 302.

Yes, so was I. I think you can use Serial1.begin(3300); but I have never tried it. That is a job for the OP - if he is still interested.

...R

dlloyd: Does [setting the baud rate to 3300] set UBRR to 302 on the Atmega328P?

On an Uno at 16MHz it is set it to 605. It's twice the number you predicted because it also sets the double speed bit.

robtillaart: I've investigated any baud rate with SWSerial in the past here - http://forum.arduino.cc/index.php?topic=138497.0 -

In practice any baudrate above 70~80Kbit fails - also discussed in that thread, however I did not investigate the low end of baudrates.

SoftwareSerial seems like a poor choice for low baud rates because it runs with interrupts disabled. Aside from missing timer ticks at 4800 baud and below it also ties up the processor. It's essentially like calling a version of delay() that runs with interrupts off. Unless minimal jitter is of utmost importance it seems like a timer-based interrupt driven approach like Robin suggested is more practical.

But I can't really figure out what computertron is doing from his partial description.