Unexpected Characters on RS485 Data Stream

General
1

I'm brand new to Node-RED and RS485. I'm looking at an incoming RS485 data stream from a Cummins-Onan generator, hoping to eventually decode it. The RS485 lines are connected to a DTech USB adapter, then to my windows PC.

  • Using Node-RED, I get data that looks like this: "���� ...""
  • Using different software (Free Device Monitoring Studio or CleverTerm, for example), the data is closer to expected: "f3 03 11 10 03 f2 c0 02 10 11 c3 c0 02 11 10 c3 c0 02 10 11 c3 c0 ...", and I can eventually see a pattern where parts of the stream begin to repeat.
  • Viewing the same data stream on a Raspberry Pi with Node-RED, it looks like the first example with garbled characters.
  • Viewing the same data stream on a Raspberry Pi with Node-RED, but this time using an RS485 CAN HAT, it again looks like the first example.

I read another post where the strange characters could be caused by incorrect baud rate. I viewed the incoming RS485 data stream on an oscilloscope. It looked pretty clean, and I measured the smallest pulse width at 104 uS, so I selected 9600 baud rate.

So I think the problem may be in Node-RED because it appears ok with other software. Does anyone know of any settings in Node-RED that could be causing the data problem? Any other suggestions?

Thank-you

2

Try setting the serial port config (where you setup the baud rate) to deliver buffers instead of ASCII Strings.

3

Are you looking at a raw frame or formatted data in a message buffer?

there will be data in a frame 'message' over a serial link that is associated with the underlying protocol as opposed to the data you are expecting.

For example if you set up RS232 to collect messages that are identified as complete when you receives a 'newline' that character will not appear in the message that is in the message buffer but if you look at the raw data buffer each message will be separated by a 'newline'.

Can and Modbus will transfer all sorts of stuff that isn't your message.

To be fair you probably dont need to worry about any of this provided you receive buffer is correctly configured to match whatever protocol settings the sender is using.

Al

4

I suspect the problem is that the serial node is configured to output a string rather than a buffer.

5

Hi, thank-you for the quick replies.

I think it was a combination of both of suggestions.

I tried Colin's suggestion and switched from ASCII to buffers. The debug window showed a bunch of integers, which I couldn't interpret.

To answer Dyslexicbloke's question, I'm not sure. The debug window was set to display msg, but I changed it to complete msg object. This, along with binary buffers as Colin suggested, and it looks like I'm now displaying the complete raw RS485 data.

So now, how do I know if I have the correct settings (data bits, stop bits, parity, etc)?

Once I figure this part out, how can I tell where the actual message payload begins?

Keep in mind that I'm brand new to this, and the company (Cummins-Onan) provided no information except for the system schematic that identified the line as RS485.

6

Does the manufacturer not publish any information on the comms? Is it one of the standard protocols?

Do you have any software that is designed to work with the device?

7

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.