Spectrotilt 12bit RS232 help needed

I am trying to read Data from a Spectrotilt 12bit sensor into serial1 on a mega 2560. The Sensor output is two bytes sent every 15ms. I need to pluck the 6 least significant bits from each byte and concatenate them to form the 12bit value. In between the 2 byte sets the sensor goes high so it looks like 14 or 15 1s on the serial stream. I can probably figure out how to parse the bytes ok but I'm stumped on just getting the two bytes tucked into variables reliably and filtering out the unwanted 1s. Any kick in the right direction will be appreciated.

Using serial read prints out a 1-7bit and 1-8bit byte.
void setup() {

void loop() {
if (Serial1.available() > 1) {
int MSB = Serial1.read();
int LSB = Serial1.read();

Serial.println("I received: ");


Prints this:

Comm protocols for the sensor:

That sounds like normal digital communications with a stop bit. That is exactly how asynchronous communication works. Perhaps the data sheet for the sensor would give a better explanation.

1 Like

The most significant bit D7 can be used for synchronization. Use that to identify and parse the MS byte, then just take the next one as the LS byte. Easy peasy. The UART ignores bits between characters so you don't even have to worry about them.

1 Like

Until you fix this to read one byte at a time and test the HO bit to see which byte to store it in, there is not much more to help with.
I have a suspicion the device is sending the HO bit first, instead of the ASCII convention of sending the LO bit first, but can't tell without more information,

1 Like

Well this was embarrassing :rofl: a full day of hair pulling because I thought that even parity was the default. I've read that data sheet a hundred times and missed one detail. Serial1.begin(9600,SERIAL_8E1) fixed it. I'm getting what I expect to see now. Thank you.

That is good! But you still need to be able to put the bytes into the matching place.

1 Like

You're right. I jumped the gun on thinking I had it fixed. At least I'm getting two 8 bit values now. lol
Let me work on this for a bit before I ask for more help. I really appreciate your advice. Thank you.

My concern is the bit 8 they mention the same as your bit 8 or is it your bit 0.
Depends on the order they transmit the bits.

1 Like

Do you have a model number? They make a LOT of tilt sensors.

Is it this one?
SSY0185-VDS12 Vertical mount
SSY0185-HDS12 Horizontal mount

Are you giving it the 7-14V power it needs?

1 Like

I don't think that is right. When you turn on 'parity' you get an additional bit after the data bits. The data already has its own parity bit (bit 6) so you should not expect a 9th bit.

1 Like

Apparently the software never checks the USART status, so the error is ignored.

They transmit backwards as you suspected.

I am supplying it with 12v from a power supply right now.

[quote="johnwasser, post:10, topic:895058"]
I don't think that is right. When you turn on 'parity' you get an additional bit

Yes. Logic level Rs232 12bit.

That's not the way I remember it, but I've been wrong before. Perhaps I do agree with you if I'm not confused... My recollection is that parity only defines the use of the bit, there are the same number of bits in the frame. So no parity, even parity, odd parity all have 8 bits if it's a 10 bit frame. Bit 7 is the UART parity, bit 6 is the application parity bit. I believe the device has no UART parity, communications with it should be configured for NO parity.

The EVEN parity they refer to, is the application (payload) parity bit 6. bit 7 alternates between 1 and 0 to indicate the upper/lower byte. It's a 10 bit frame:
upper/lower indication bit
7 data bits B0-B6

In fact, the whole point of using NO parity is typically to allow the transmission of full bytes.

1 Like

Yes, on transmitting. On receive the USART likely test, but just sets a bit in the status register, which is ignored.

1 Like

Correct. As the old saying, it takes two to tango. With no protocol for error recovery or even acknowledgement, there is no reason to report errors.

1 Like

...and, another view of that is, even with multibyte error detection in place there is no need for parity. If I recall correctly parity was originally introduced for punched paper tape, to improve the read accuracy. But of course it took off with digital communications. Originally, those continued the history of the 7 bit code of the Teletype machine, which IIRC had two stop bits. This meant the second last bit had to be a zero for the TTY or printer, but could be redefined as a parity or as an extended character set flag by redefining the frame as having only one stop bit. This maintained at least the possibility of making a TTY work with a serial line or modem. Also enabling an 8 bit data payload. Thus ASCII "plus". As you say, the crucial importance is on error handling. Indeed what is the point of detecting an error if you can't do anything useful.

1 Like

Sorry for the delay, moving my daughter into the dorm...
I changed the config back to the default 8N1. I am getting the two bytes from the buffer and the numbers I'm getting from the 6bits of each jive with what I expect to see from the sensor, only the leading zeros on the LSB are omitted and I'm guessing that is why I am seeing 7 or less characters on one of the two bytes. Does that sound like I am on the right track? I've tried changing data types to get my variable to populate with a full 8 bits but I haven't figured that out yet. So my plan for experimentation as it sits: I need to test for the leading 1 or full 8 bits to determine which of the two bytes are are the MSB. I can pluck the 6bits from each of the bytes and concatenate. A question for me to figure out is If the LSB is < 16DEC will a bit read insert a zero if there is nothing in that bit?

I'll let all of you know if I make any progress, or I'll come back begging for one of you to shoot me. :slight_smile: I can't thank you all enough for helping me.