Extra Bit in Serial Transmission

[Mellobuck]

Good Morning,

I am trying to replicate a board level serial communication, so that I can test a UUT independently of the entire system. The messages to be sent are very simple, in hex 00 FF 00 FF 00 FF or 00 FF 01 FE 00 FF. My customer was able to capture the communication occurring in a fully assembled system:

The message is inverted, so the 0x00 is 11111111, 0xFF is 00000000, plus the start/stop partity bits etc.


But when I try to replicate this in LabVIEW, I get an extra bit showing up between the FF and next 00 message (see scope trace here):

I think it is also there at the end of the 0x00 frame, but it blends into the other data.

Same thing happens when trying to send 0x00 0xFE:

I am attaching the code used to generate the serial, trying to figure out a way in the VISA properties to remove this extra data, as the microprocessor does not seem to be getting the messages.

Hardware: SeaLevel systems ISO COMM2 PCIe isolated 2-port RS-232 device, running in 9 bit protocol.

I have attached the VI I was using to send the serial commands (LV 2019), but it is just a serial tester where I can arbitrarily send strings with different serial settings.
I am getting back expected message values, so the serial connection settings appear to be at least close.

Things I have tried:

• Changing the parity bit across all five settings has no effect
• Tried changing stop bits, but the system needs just one stop bit
• Using both write termination characters, and no termination (current)

Is there a property or method I am missing here?

Thank you,

[crossrulz]

Per UART, you need a Start Bit and a Stop Bit.  Assuming 8 bit data, this would be a total of 10 bits per byte of data.  The extra pulse you see in there I would suspect is the parity bit.  You should probably have that turned off (set to NONE).

The other thing that might be throwing you off is that RS-232 defines a positive voltage as a 0 and a negative voltage as a 1.  That is why the values seem inverted. (RS-232 - Wikipedia)

---

@Mellobuck wrote:

Hardware: SeaLevel systems ISO COMM2 PCIe isolated 2-port RS-232 device, running in 9 bit protocol.

---

What is this "9-bit protocol"?  Your customer's plot looks like basic RS-232 with 8 data bits, 1 stop bit, no flow control, and no parity.  I'll trust you have the baud rate correct.

[crossrulz]

Ok, I just did some digging.  There are some devices that use a 9-bit protocol with that extra bit being used for addressing or some other control signal.  Turn that feature off on your card.

[Mellobuck]

The unit under test is requiring 9 bit protocol to communicate. If I turn it off I get nothing back, and no reaction to any messages sent. From the on-board source code of the UUT I did confirm the 9 bit protocol and the (admittedly unusual) baud rate.

The UUT can receive a message that is all Zeros, it is when I try the 01 or similar that this issue arises. 

[Mellobuck]

Thank you very much for combing through this for me.

I cycled through every parity method just now, including None, and it seemed to have no effect on that extra bit

I also went into the 9-bit protocol in the hardware configuration and turned it off to make sure that wasn't causing it, and the same result. 

I suspect this is the stop bit, but I understand that it should be the same level (low) as the idle state of the line.

I will keep trying some other settings