UART Serial Communication

[sheltonfilms]

I'm trying to use a rotary encoder (shown **broken link removed**) for a school project. It has a serial connection and uses UART to send back rotary position.

To obtain the absolute position you send 00 in Hex to the device and it then sends back a HEX equivalent of 0-360 degrees.

Instead of a PC for my project it will be connected to an Arduino Uno board. Since my project is very time dependent, I don't want to waste even one clock cycle on sending the "00" to the device constantly.

Is there a sweet but simple circuit I could build that just keeps sending the "00" request command using UART to the device? Looking at speeds of 10kHz or sends the request every 100 microseconds.

Thanks guys for your time.

 

[Nigel Goodwin]

Why not a timer routine on the AVR?, and send it every 100uS, or call the routine from the main program loop.

However, 100uS seems excessively fast - it's a mechanical device, and it shouldn't need checking anywhere near that often.

 

[sheltonfilms]

Its a camless engine design and we are using the encoder on the crankshaft to tell the computer when and at what positions to actuate the valves to. It uses the rotation position as a independent variable in a sinusoidal function. At 3600 RPMs, and a sampling rate of 10kHz, each sample will show a difference of 2.16 degrees.

The encoder is actually contact-less, I would assume using Hall effect sensors. The update rate of the sensor is 100us and I just want the whole system to be as accurate and precise as possible.

 

[misterT]

If I understood the datasheet correctly, it takes ~520 microseconds for the sensor to send one position information through uart (2 bytes at 38400 baud). So there is no point trying to read the device at 100 us intervals. You cant even send the "request data" -byte fast enough. The fastest "data read interval" you can get with uart is ~900 us.

The SPI interface of the sensor can communicate at 350 kbps. You should use the SPI, but even then the maximum "data read interval" you get is ~200 microseconds.

 

[BrownOut]

It could work if the UART is >300K baud capable. The datasheet didn't say what the capabilities were, only what the default rate is. It doesn't matter how the function code is sent, 3 bytes per sample will still be required, so you might as well just send it using the timer.

 

[misterT]

It could work if the UART is >300K baud capable. The datasheet didn't say what the capabilities were, only what the default rate is. It doesn't matter how the function code is sent, 3 bytes per sample will still be required, so you might as well just send it using the timer.

According to the datasheet the 38400 is the max. baudrate.

 

[BrownOut]

NO. That's the default baud rate. It doesn't say what the max rate is.

 

[misterT]

The data sheet lists the available baud rate options:

3   Shift to instructed baud rate by L for UART mode only 
    L = 0 : 38400 
    L = 1 : 19200
    L = 2 : 9600 
    L = 3 : 4800

So, the default is also the maximum.

 

[BrownOut]

Well, that sucks. But at least with the SPI data rate of 350K BPS, the updata can get very close to 100uS.

 

[misterT]

Well, that sucks. But at least with the SPI data rate of 350K BPS, the updata can get very close to 100uS.

Well, I think you have to spend 100us to send the request and then it takes 100us to get the data, so the max. updata is around 200us.
But, anyway, the SPI is much better way to communicate with the sensor.

 

[BrownOut]

It should only take 8/350k = 22.8uS to request the data, and 16/350k = 45.7uS to read it, and two 10uS inter byte waiting periods. Total time is ~90uS per read. I can't translate what they are saying about the "suggest interval time" though.

 

[misterT]

The SPI request is different from the UART request. The SPI request is 3 bytes.

And on top of that the datasheet says:

For consecutive read by repeating packet2, suggested interval time
Between two reading packet be N x 100(us), N = 1,2,3,.. such as 100,
200,300,400,..(us)

So if you can request at 100us intervals and the receiving of data takes 85us, the total is around 200us.

Or, is SPI full dublex bus?

 

[BrownOut]

Yes, SPI is full-duplex. Serial Peripheral Interface Bus - Wikipedia, the free encyclopedia

I missed how SPI mode has a different request sequence.

 

[misterT]

Yes, SPI is full-duplex. Serial Peripheral Interface Bus - Wikipedia, the free encyclopedia

Ok, I missed that info . So it is possible to achieve 100us updata interval. But the data will probably have at least 100us of delay.

 

[Mr RB]

I don't think that absolute encoder sensor is a good fit for that purpose, because of the speed and timing issues etc.

A better system would be similar to what cars use for ignition systems; an on/off hall sensor mounted some degrees before top dead centre then calculate degrees based on time, which never varies more than a percent or so from one engine rev to the next. A slightly better system is to use a multiple pulse sensor (say 32 pulses per rev) and a single pulse per rev sensor at TDC. That is also typical in auto applications.

 

[sheltonfilms]

I don't think that absolute encoder sensor is a good fit for that purpose, because of the speed and timing issues etc.

A better system would be similar to what cars use for ignition systems; an on/off hall sensor mounted some degrees before top dead centre then calculate degrees based on time, which never varies more than a percent or so from one engine rev to the next. A slightly better system is to use a multiple pulse sensor (say 32 pulses per rev) and a single pulse per rev sensor at TDC. That is also typical in auto applications.

But if you power off and power on the system doesn't it lose the position? But I guess that is why you add the extra sensor at TDC to zero out the position.

 

[Mr RB]

Correct. It always requires one revolution to sync the system first.