Reading data from RS485 interface connected to a device returns ghost bytes when reading with .NET


I’m completely at a loss here.
We have a device that sends data over an RS485 interface.
When reading this data with any tool not written in .NET, the received data is correct
(Reading using realterm, putty, etc…)

For example we receive:

01 00 56 00 00 01 00 57 57
01 00 56 00 00 01 00 57 57
01 00 56 00 00 01 00 57 57

As soon as we try to read from the same device using a .NET application
we see ghost bytes:

3F 3F 3F 01 00 56 00 00 01 00 57 57
3F 01 00 56 00 00 01 00 57 57
3F 3F 3F 01 00 56 00 00 01 00 57 57

The value is always 3F.

If we monitor the serial interace using a serial port monitor
and read using a .NET app we also see the 3F bytes,
if we monitor and read using putty, realterm, etc…
we do not see the 3F bytes.

If we connect another pc to the other end instead of the device,
and we read data, we do not see the 3F bytes, all data is 100% correct.

It doesn’t matter what PC we run the code on
or what RS485 interface we are using.

We have tried USB-RS485 connectors (multiple from different brands),
USB-RS232 connectors connected to RS232-RS485 converters (multiple from different brands)

The result is always the same.

If we try to read data from the RS485 device using a Fez Panda II with
an RS485 interface, we see the data arrive on the pins using a scope,
we see the data in eltima, but the Fez Panda II never received any data.

If we send data from the computer to that same Panda II the
panda can read the data no problem.

Note that it makes no difference whether we try to read the data
using the OnDataReceived event or by forcing a read ourselves.

My hardware developer is persisting the problem must be in .NET

At this point I don’t know what to believe.

I’ve written lots of apps that deal with serial data in .NET
and there aren’t exactly many variations of how to read serial data in .NET

Below is just one of the variations of the code used to read

void port_DataReceived(object sender, SerialDataReceivedEventArgs e)
    var bytesToRead = port.BytesToRead;
    var totalRead = 0;
    while (bytesToRead > 0)
        var buffer = new byte[bytesToRead];
        var read = port.Read(buffer, 0, buffer.Length);
        totalRead += read;

        foreach (byte b in buffer)
            Console.Write("0x{0:X} ", b);

        bytesToRead = port.BytesToRead;

    Console.WriteLine(" --- {0} bytes", totalRead);

For the Panda the event isn’t even triggered when receiving data from the RS485 device
(it is triggered when receiving data from another computer though)

void prismaPort_DataReceived(object sender, SerialDataReceivedEventArgs e)
            var count = prismaPort.BytesToRead;
            while (count > 0)
                byte[] buffer = new byte[count];
                var read = prismaPort.Read(buffer, 0, count);  
                foreach (byte b in buffer)

                count = prismaPort.BytesToRead;

            Debug.Print("Finished reading");

And yes the event handler is hooked up after the port is open,
and even when forcing a read without event handlers, the read waits forever
when the data comes form the device.

So it seems the .NET code can receive correct data from anything other than the device
It receives 3F bytes when reading from the device if the code runs on a PC
It does not receive any bytes when reading from the device if the code runs on a Panda (we have over a hundred panda’s, so we tried multiple ones to rule out panda malfunctions)
Any other app can receive data from the RS485 device

Does anybody have any idea?

verify baudrate, verify for parity mismatch, verify number of stopbits…

What do you mean with “the device”? Have you measured the bitrate of “the device” with a scope? It might be out of range? F.e. 115200 on one device is not the same as 115200 on an other device. You always have error depending on the oscillator used (f.e. a crystal of 18.432 Mhz will give you a perfect timing, while when using a 16Mhz clock you’ll have a small error). If I remember right that error must be smaller then 10%

Can you also post a schematic on how you connected the RS-485 chip to the panda and to the PC?

[quote]Can you also post a schematic on how you connected the RS-485 chip to the panda and to the PC?

At first I wondered whether there was only an RS485 to USB connector or a chain of RS485 -> RS232 -> USB and whether that is actually the problem - so your question will be very important to know the answer to ! I wouldn’t put any faith in all those “serial” bus changes so you want to get a proper connection with only one TTL->485 converter.

Edit: the 3F is an ascii question mark, ?. So I think that is likely a comms issue.

Thnx for the replies. Will try and post the schematics, need to clear it here first.

Anyway, now the Panda can receive data BUT

If we put the panda and a pc and the device on the same RS485 line
we can use the PC to monitor the data between the device and the panda.

If we let the computer send a request to the device (the device has an api and receives/sends data, that’s it)
then device responds to the computer.

Here’s the strange thing the Panda sees ALL the data sent from the PC but only sees 2 bytes from the device. (Always bytes at the same position, 7 and 10 in the stream)

So the panda can receive data on the RS485 from ANYTHING , except the RS485 device.
PC’s can receive the data from ths RS485 device.

We then stopped using the RS485 interface on the PCB… And used a PAnda – RS232/RS485 — DEvice setup.

The result is exactly the same… the panda sees all the data from the PC but only 2 bytes from the device, the pc sees all bytes from the device.

So it’s not RS485 related.

So my question is, what might the device be doing that renders the panda unable to read all the data.

Note all replies have the same length and it’s always the same 2 bytes that the panda can see.

As I suggested before, I think you have a timing issue there… verify and compare bittimings of PC, “the device” and the panda with a scope.

Btw: how can you have 2 masters (PC and “the device”) on a single RS-485 bus?

Are you using full or half-duplex RS-485?

0x3F 0x3F looks like a square wave on the communication lines, so a scope measurement would be nice

Thnx for all the suggestions.

Here is what happened.
The developer of the device firmware enabled Parity.Mark.
On it’s own not a problem except for the fact that it didn’t really work.

Causing communication with both Mark enabled or disabled on the panda to simply fail.
After disabling mark on both devices everything worked perfectly.

Later I ran a test with 2 computers where one would enable Mark and the other wouldn’t.

As a result 0x3F bytes could be seen on the line.

Thnx for the suggestions!