Not expected values...

I ve got a little problem, i m working with a serial device with a known protocol and using 19200 8n1, i use a teensy set up as a virtual com port device so i can use serial terminal or real term to read the data coming from the device. But the values i got don’t match what i expect. The packet length are good, i need 5 bytes packet, but the values are messed up.

Exemple : I should have that type of value (decimal) : 241 ( hook byte ), 63(values can go from 0 to 127),13 (values can go from 4 to 22) ,63 ( can go 0 to 127 ) and 10 ( can go 4 to 17 ).

But what i get i an hex which looks like this : 87 67 F5 22 00 in decimal : 135,103,245,34,0 so obviously not really what i expect…
What can mess up my data packet like this ?
Any help is welcome.

i m working with a serial device with a known protocol and using 19200 8n1

TTL or RS232?
If the latter, what is doing the level conversion and inversion?

that's the tricky part, the device is labelled rs232 but it output 5v ttl level signals.

That's OK - if the device is RS232, the voltages could be +/- 5V (NOT TTL), but inverted wrt true TTL.

So i should convert them somehow ? Heres the sketch i use to monitor thing on REALTERM.

//  echo on TX (pin1) from RX software (pin 2)

#include <NewSoftSerial.h>


NewSoftSerial tabletteSerial(2, 3); 

void setup()  
{
  Serial.begin(19200);         Serial.println("Bonjour");

  tabletteSerial.begin(19200);
}

void loop()                     
{
  if (tabletteSerial.available()) {
      Serial.print((char)tabletteSerial.read());
  }
}

First mention of softwareserial.
You could try the "invert" optional parameter to "begin"

NewSoftSerial myInvertedConn(7, 5, true); // this device uses inverted signaling
NewSoftSerial myGPS(3, 2); // this one doesn't

i ve done it, as expect i ve got new sets of HEX values, but still no sign of the value expected, and now in realterm i ve got a lot of "break" and "error" while receiving the packets....

OTher way to invert is to do

Serial.print((char)(255 - tabletteSerial.read()));

Do you have a datasheet link of the device in question ?

same, new values but still no signs of the expected ones. And a lot of break and error.
For the datasheet, there is one, but not really filled with infos, but there is a lot of stuff on the website, what should i look for ?
( its the same tablet device i started a thread about in device hacking : SignatureGem 4x5 Signature Pad - Topaz Systems ).

OTher way to invert is to do

Serial.print((char)(255 - tabletteSerial.read()));

That's assuming that the start bit was recognised correctly.

ok progressions :slight_smile:
i modified the sketch using the inverted "(true)" parameters, i ve got errors but i manage to correct it because i forgot to set all the serial the soft one and the hard one to 19200.
I know have the expected first bytes which are the status of the stylus. And they re correct. But the following bytes are still not what i expect, the values are too high. and i have a packet of 6 bytes instead of 5 ... i presume there is a separator or stop byte in this ?
i m wondering if it's not a "parity bit" problem... how could i change the parity in newsoftserial ?

I just had a quick look at the library, and after the eight data bits, the receiver simply skips the stop bit, and then presumably re-arms ready for the next character.
I guess you could slip in an extra " tunedDelay(_rx_delay_stopbit)" to skip parity too.

i tried but have some not declared errors, should i add this delay in the void loop when serial.available ? or in the setup ?

echorxsoftpin2:21: error: '_rx_delay_stopbit' was not declared in this scope
echorxsoftpin2:21: error: 'tunedDelay' was not declared in this scope

i tried but have some not declared errors, should i add this delay in the void loop when serial.available ? or in the setup ?

Neither; in the library.
You may want to add a "parity" flag to the "begin" method.

Ok so i should open newsoftserial.h and edit tuneddelay to 1 ?
And then flag the parity in the begin like serial.Begin(19200, N) ?

ok in the library i see :
// skip the stop bit

tunedDelay(_rx_delay_stopbit);
DebugPulse(_DEBUG_PIN2, 1);

so i should add
// skip the parity bit
tunedDelay(_rx_delay_paritybit);
DebugPulse(_DEBUG_PIN2,1);

?

Yes, I think that's where I'd put it, but make it conditional upon the parity flag (for guidance, look at the "inverse_logic" flag, which I failed to notice is in the constructor, not the "begin" method)

ok i ve noticed the inverse_logic flag, but i thing it exceed my programming competence, i have no idea what should i do to it, and make the good conditionnal value for my extra stop bit..

ok, i ve added the extra skip parity bit

without making conditionnal ( because i still don't know how to do it )
But i can say that now my 5 bytes packet are looking good.
You helped me a lot :slight_smile: thanks

first, third and fitth byte, are getting me the values i expect, not sure about second and forth thought... but seems impossible that i can get some bytes right and the other wrong ? or is it ?

How "wrong" are they?
Even if there's a severe speed mismatch, the receiver should re-sync at the start of each character, so any problems should affect all characters equally - the receiver has no concept of packets.