RS232 - MS_CTS_ON voltage level?

Discussion in 'Programmer's Corner' started by bordonbert, Jul 11, 2019.

  1. bordonbert

    Thread Starter Active Member

    Feb 21, 2012
    31
    0
    I have a console test app to verify a legacy unit which responds over an old fashioned RS232 Serial line. It's a simple manual setup which requires a button push on the box in response to a buzzer signal sent from the controlling PC. This is a simple setup but a serious application, it's used in seismic surveying to mark the deployment of sonar devices on an ocean bottom cable.

    The system sends out its "within window" beep on the RTS line and then listens on the CTS line for a change of state caused by the button press on the external box to verify deployment of the next device. The box simply generates a 5ms negative going pulse on the CTS line representing an OFF state to an ON state, (it's RS232 so OFF is a +ve voltage and ON is a -ve one so it needs to be a +ve to -ve transistion which gets detected).

    I'm using this code:

    if (WaitCommEvent(hComm, &dwEvent, NULL)) {
    .....if (dwEvent & EV_CTS) {
    ..........DWORD dwCommStatus = 0;
    ..........GetCommModemStatus(hComm, &dwCommStatus);
    ..........if (MS_CTS_ON & dwCommStatus) {
    ...............printf("\n CTS change detected. CTS test terminating.\n");
    ...............//DO STUFF!
    ..........}
    .....}
    }

    I have no problem with the coding to get a response, the app responds to the pulse reliably so hardware seems fine. My problem is that I seem to have something hanging around in the system which causes oddities after the initial response. I had wondered if the Modem Status firstly responds to the correct falling edge but then also generates another secondary response due to the rising edge which would not be set for MS_CTS_ON. I am wondering if I may have to set something to remove the rising edge response otherwise that secondary response is left in the buffer so my software responds to it immediately the next call to GetCommModemStatus() is made. Of course that would givew a FALSE response to "if (MS_CTS_ON & dwCommStatus) {}"

    Is there a possibility there is anything in all of this rambling?
     
  2. bordonbert

    Thread Starter Active Member

    Feb 21, 2012
    31
    0
    I've done a bit more toying with the code and found that this does seem to be a real problem. If I add in an alternative "else" to the last "if" like this:

    ..........if (MS_CTS_ON & dwCommStatus) {
    ...............printf("\n CTS change detected. CTS test terminating.\n");
    ...............//DO STUFF!
    ..........} else {
    ...............printf("Second response, not MS_CTS_ON, detected");
    ..........}

    I always get a response to my button press but the next time the same test process is initiated it immediately gives a hit without any input from me and displays that new message. Selecting the test process once again after that sets it back to respond correctly and it waits for the button press. Every time I get a correct response it is followed by the incorrect one. The test has to be selected twice for each run, once to test response and once to purge the setup. It does look as though both the falling edge and the rising edge of my single pulse initiate CTS change events which are being held somewhere in a queue and responded to in turn each time WaitCommEvent() is called.

    If this is known logical behaviour I would appreciate anyone just confirming it to be sure I am not making a ridiculous assumption. I would also like to know if there is a correct way to purge the queue after each correct pass.
     
Loading...