Data Event: Does not Receive Message in One Data Block => Message is Mixed Up With Sent Message

[360disrupt]

Operating System and Hardware:
NodeJS Version: 5.0.0
Serialport version: 3.1.2

Configuration of the Serialport

options = {baudrate: 9600, dataBits: 8, stopBits: 1, parity:'none'}

Configuration Guideline in the ccTalk Manual

ccTalk
Bi-directional data line
9600
8-bit or 16-bit CRC
1,8,1 // 1 start bit, 8 bit message, 1 stop bit 
no parity
Retail & AWP

9600 baud, 1 start bit, 8 data bits, no parity bit, 1 stop bit
RS232 handshaking signals ( RTS, CTS, DTR, DCD, DSR ) are not supported. This is a small data packet control protocol and data overruns are not likely to occur.
There are 10 bits needed for each transmitted byte - 8 data bits + 1 start bit + 1 stop bit. No parity bit is used. Error detection is achieved through a packet checksum.

Expected behavior

• Receiving a data event with the sent message.
• Receiving a response data event with the full & only the response message.

Actual behavior

• Sometimes as expected, sometimes mixed up messages, e.g.
  expected:

80,0,1,246,185 //This is the sent message
1,3,80,0,87,72,77,192 // This is the received message

not expected:

-------------------------------------------
80
0,1,246,185,1,3,80,0,87,72,77,192
-------------------------------------------
80,0
1,246,185,1,3,80,0,87,72,77,192
-------------------------------------------
80,0
1,246,185,1,3,80,0,87,72,77,192
-------------------------------------------
80,0,1,246,185,1
3,80,0,87,72,77,192
-------------------------------------------
80,0,1,246,185,1,3,80,0,87,72,77
192
-------------------------------------------
80
0,1,246,185,1,3,80,0,87,72,77,192
-------------------------------------------
80,0,1,246,185,1,3,80,0,87,72,77,192
-------------------------------------------
80,0,1,246,185,1,3,80,0,87,72,77,192
-------------------------------------------
80,0,1,246,185,1,3,80,0,87
72,77,192

Comment

I'm not sure if this is expected behavior, a failure related to the module e.g. ignoring the stop bit?

[reconbot]

Data events contain all the data we get from the operating system whenever we're notified of data and read for it. Because of that you're never guaranteed to have all of a response in one event.

The config you're specifying is the default config for a port. Same as every arduino and hundreds of other devices we're talking to.

You're saying we're giving you sent data too? That's not a bug in serialport, you'd have to be getting that back from your device.

And some extra garbage data? I'm feeling that might be coming from your device too.

It's not clear to me from your unexpected section what your sending and receiving and when. Do you have sample code?

[360disrupt]

you're never guaranteed to have all of a response in one event

Ok I thought it should be like that.

I have a different parsing application, this application has and end event. I thought if there is no end event, than the response must be in one data event. Seems I guessed wrong.

Then I will create a buffer, remove the original msg and check the rest of the msg bytes until I get the required length. Or is there any way to know when a response is finished?

[reconbot]

We have a byte length parser that will emit data every X number of bytes, but we don't have a way to say "Wait for the next X bytes" built in out of the box. https://github.com/EmergingTechnologyAdvisors/node-serialport/blob/master/lib/parsers.js#L30-L40

[frank-dspeed]

@360disrupt this is solved via PR: #1342

[reconbot]

Wrong issue @frank-dspeed?

[frank-dspeed]

@reconbot not really i think he don't understands that right and it was parser related many coders that try to mess with the cctalk protocol don't understand how it really works they understand how to send the first commands but real communication is more complex i run many cctalk devices with that lib i know the problems :) pointing him to the parser will help him to understand what to do

his current situation is he writes to the port (gets also what he writes to the port) and is parsing that to slow and so he also gets the answer mixed into his reply :)

the timing of cctalk is really evil some devices need to get polled for example every 200ms :)

[frank-dspeed]

maybe as little additional hint if he re reads that:

i use internal a so called promise chain. to execute only one command in a single time frame and wait for the response i also use promise timeout to make the bus free for new commands but 1 command at time is importent to get only 1 reply at time from only 1 device at the bus!!!!!!