[RESOLVED] Serial communication protocole : RTS/CTS

[Francois_P]

Hello coders !


I am currently building an acquisition software for a sensor communicating in UART via USB.
The first parameters for the communication are easy to deal with : baudrate, databits, stopbits, parity... All clear ! So I can recieve messages and read them.

The problem appears when I start sending requests : sometimes it works fine, sometimes the sensor stops communicating.
I think there is an issue with the protocole. The sensors datasheet indicates "a RTS-CTS control flow is used", but this option doesn't exist in the VBnet serialport object.
I found two properties which relate to this :
- Handshake https://bit.ly/2SfruFR
- and RtsEnable https://bit.ly/2GfiBFJ
I played around with these but cannot seem to make it work consistently...


So... what is the proper way to configurate this ?
Thanks a lot to anyone who could help !
Francois

[passel]

I believe that RTS-CTS is supported. You have to set the Handshake to comRTS, and enable the RTS line.
Of course, your serial cable has to have the CTS and RTS pins wired between the port and the device. But, I haven't had to use hardware handshaking, so can say definitively that is all there is to it.

[Francois_P]

Hello, thanks for the answer passel !

If I understand well, I should set the Handshake property to Ports.Handshake.RequestToSend and the RtsEnable property to True.
Should I also check the state of the CtsHolding property before I send data ?

I coded this as a first attempt, but since I don't have a clear understanding of the protocole, I don't know if it is useful...

    Public Function send(message As Byte()) As Boolean
        Dim Timeout As Date = Now().AddMilliseconds(500)
        While (Now() < Timeout)
            Threading.Thread.Sleep(10)
            If _sp_serialPort.CtsHolding Then
                Me._sp_serialPort.Write(message, 0, message.Count)
                Return True
            End If
        End While
        Return False
    End Function

[2kaud]

Back in the old days, this sort of thing was easy to diagnose and fix. With RS232 serial cables, you used a break-out box tester which was inserted in-line with the serial cable and which showed what was happening with the data, control signals etc. Pins were patched until it worked and then the cable(s) in the RS232 plug(s) were altered accordingly. Everything sorted in a few minutes. Now, however, with serial-over-usb and 'virtual' com ports things aren't as straight forward as you can't insert test gear in-line with a usb cable like you could with good old RS232!

First, I suggest you obtain a good terminal emulation program (one that shows the control signals [eg rts/cts etc] and allows these to be changed). Then get your communication with the device working using the terminal emulator. Once that is working, then look to your program.

Second, consider getting a couple of usb-RS232 adaptors, a RS232 tester break-out box (one that allows pins to be cross-coupled using jumper wires) and some RS232 cables. Then connect one usb adaptor to the equipment, using a RS232 cable connect this to the break-out box, then another RS232 cable to the other usb-adaptor and plug this into the computer. Then you can monitor on the break-out box what is happening on the serial interface, set control signals etc etc until it works with the terminal emulator. Then you can test your program.

Without knowing what is happening over the serial interface, you're working blind and guessing.

[2kaud]

I believe that RTS-CTS is supported. You have to set the Handshake to comRTS, and enable the RTS line.
Of course, your serial cable has to have the CTS and RTS pins wired between the port and the device. But, I haven't had to use hardware handshaking, so can say definitively that is all there is to it.

The OP is using serial-over-USB so there's no physical pins as they used to be! Even if there was, you need to know whether the device is acting as a DTE or a DCE. DTE to DCE requires straight pin connection, whereas DCE/DCE or DTE/DTE requires x-pin connection.

[dbasnett]

Hello, thanks for the answer passel !

If I understand well, I should set the Handshake property to Ports.Handshake.RequestToSend and the RtsEnable property to True.
Should I also check the state of the CtsHolding property before I send data ?

I coded this as a first attempt, but since I don't have a clear understanding of the protocole, I don't know if it is useful...

    Public Function send(message As Byte()) As Boolean
        Dim Timeout As Date = Now().AddMilliseconds(500)
        While (Now() < Timeout)
            Threading.Thread.Sleep(10)
            If _sp_serialPort.CtsHolding Then
                Me._sp_serialPort.Write(message, 0, message.Count)
                Return True
            End If
        End While
        Return False
    End Function

Enable RTS and use the code above, though I'd move the sleep to after the check for CTS. One other thing, the above code should NOT be run on the UI thread.

[topshot]

I didn't realize USB adapters would do hardware flow control (most really don't as I suspected) but there are some that do so verify that yours can.

I don't think you need to look at CtsHolding. It should not allow your Write automatically unless it sees that. You can set WriteTimeout to keep from getting stuck.

[2kaud]

Whether a serial USB supports control signals (ie RTS/CTS etc) is down to the particular virtual com port usb driver used. The one I use does.

I'm not a .net programmer (c/c++) so can't comment on the VB code, but the settings for a serial port are specified at the low API level by the DCB (Device Control Block) and GetCommState(), SetCommState() etc. See https://msdn.microsoft.com/en-us/lib...#serial_topic6 which has a section on Serial Settings and a description of the various elements of the DCB structure. It also describes how to determine if loss of data is due to flow-control issues (Flow Control section).

Sorry this isn't .net focused, but it may help in understanding issues, setup etc.

[passel]

The OP is using serial-over-USB so there's no physical pins as they used to be! Even if there was, you need to know whether the device is acting as a DTE or a DCE. DTE to DCE requires straight pin connection, whereas DCE/DCE or DTE/DTE requires x-pin connection.

Well, I guess all the USB Serial devices I used were converters, so there was a DB-9 (or several DB-9) connectors on the dongle end of the USB cable. I was really referring to ensuring the required wires were in the cable connecting the two devices. We have some cables that only have three wires between the ends so wouldn't support hardware handshaking because of the lack of physical connections.

[Francois_P]

Hello everyone, and thanks for the answers !


@dbasnett:
- Ok for moving the sleep, make more sense not to wait if I don't have to.
- Ok for putting this on a specific thread.
@topshot:
- I can only guess the USB adapter does hardware control, since it was provided by the sensor's manufacturer who is telling me to use RTS/CTS...
- I don't find the msdn page for Ctsholding very clear on this : "The Clear-to-Send (CTS) line is used in Request to Send/Clear to Send (RTS/CTS) hardware handshaking. The CTS line is queried by a port before data is sent." Does it mean that this is done automatically?
@2kaud:
- You are right, everything would be clearer with a physical interface...
- Do you have an example of a good terminal emulator ?
- I will look into DCB first thing when I get back to this project. Thanks !

[Francois_P]

Hello everyone, and thanks for the answers !

@dbasnett:
- Ok for moving the sleep, make more sense not to wait if I don't have to.
- Ok for putting this on a specific thread.

@topshot:
- I can only guess the USB adapter does hardware control, since it was provided by the sensor's manufacturer who is telling me to use RTS/CTS...
- I don't find the msdn page for Ctsholding very clear on this : "The Clear-to-Send (CTS) line is used in Request to Send/Clear to Send (RTS/CTS) hardware handshaking. The CTS line is queried by a port before data is sent." Does it mean that this is done automatically?

@2kaud:
- You are right, everything would be clearer with a physical interface...
- Do you have an example of a good terminal emulator ?
- I will look into DCB first thing when I get back to this project. Thanks !

[2kaud]

I've used YAT (https://sourceforge.net/projects/y-a-terminal/). Part of its functionality is that it can show the state of the control signals.

[Mc_VB]

Rts Cts hardware flow control can be automatic or it can be controlled programmatically. Unless the sensor contains a program that can be user modified I would say the flow control is completely automatic. Setting the RequestToSend property in your VB program should be all that is needed. In many cases rts cts flow control is a suggested option but not always a necessity, it may be that you can communicate without flow control. Do you have a link to the datasheet.

[Francois_P]

Hello everyone,


I was able to communicate with the sensor's manufacturer.
Turns out I was missing the DtrEnable property which has to be set to True.

So, in the end, the configuration is the following :

        With _sp_serialPort
            .RtsEnable = True
            .DtrEnable = True
            .BaudRate = 19200
            .DataBits = 8
            .StopBits = Ports.StopBits.One
            .Parity = Ports.Parity.None
            .Handshake = Ports.Handshake.RequestToSend
        End With

Just in case, I kept the CtsHolding precaution for sending messages in my second post with a few tweeks suggested by dbasnett.
Happy ending

Thanks to all !