DSR off ... - Protocols

This is a discussion on DSR off ... - Protocols ; Hi, I wasn't able to communicate successfully between two devices using RS232. The show comm parameters are as under: /dev/ttyS0, speed:19200, mode:local, modem:none flow:rts/cts, carrier-watch ff CD ff, DSR ff, CTS:On, RI ff, DTR: on, RTS n However, on another ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: DSR off ...

  1. DSR off ...

    Hi,

    I wasn't able to communicate successfully between two devices using
    RS232. The show comm parameters are as under:

    /dev/ttyS0, speed:19200, mode:local, modem:none
    flow:rts/cts, carrier-watchff

    CDff, DSRff, CTS:On, RIff, DTR: on, RTSn

    However, on another machine, where the communication worked, I had the
    exact same comm parameters as above except that DSR was ON.

    I was wondering if through kermit can I control the DSR and set it to
    'On' so that communication works fine.

    Thanks,
    Ray

  2. Re: DSR off ...

    In article , icurmt wrote:
    : I wasn't able to communicate successfully between two devices using
    : RS232. The show comm parameters are as under:
    :
    : /dev/ttyS0, speed:19200, mode:local, modem:none
    : flow:rts/cts, carrier-watchff
    :
    : CDff, DSRff, CTS:On, RIff, DTR: on, RTSn
    :
    : However, on another machine, where the communication worked, I had the
    : exact same comm parameters as above except that DSR was ON.
    :
    : I was wondering if through kermit can I control the DSR and set it to
    : 'On' so that communication works fine.
    :
    DSR is an *incoming* signal so Kermit can't control it. You'll need to
    rig up your cable to supply it; e.g. Wire local or remote DTR back to DSR.

    - Frank

  3. Re: DSR off ...

    Frank da Cruz wrote in message news:...
    > In article , icurmt wrote:
    > : I wasn't able to communicate successfully between two devices using
    > : RS232. The show comm parameters are as under:
    > :
    > : /dev/ttyS0, speed:19200, mode:local, modem:none
    > : flow:rts/cts, carrier-watchff
    > :
    > : CDff, DSRff, CTS:On, RIff, DTR: on, RTSn
    > :
    > : However, on another machine, where the communication worked, I had the
    > : exact same comm parameters as above except that DSR was ON.
    > :
    > : I was wondering if through kermit can I control the DSR and set it to
    > : 'On' so that communication works fine.
    > :
    > DSR is an *incoming* signal so Kermit can't control it. You'll need to
    > rig up your cable to supply it; e.g. Wire local or remote DTR back to DSR.
    >
    > - Frank


    Tried and true null modem cable 25 pin D connectors
    1 ----- 1
    2 ----- 3 2 twisted pair cable 1 and 7 separate pairs
    3 ----- 2
    7 ----- 7

    4 -| |- 4 4 & 5 jumpered in each head
    5 -| |- 5

    6 -| |- 6 6 - 8 & 20 jumpered in each head
    8 -| |- 8
    20-| |-20

    Use xon xoff protocol.

    9 pin connectors do literal translation but my memory won't recall
    the pin numbers.

    Regards...Dan

  4. Re: DSR off ...

    Am I right to assume that kermit ignores any incoming messages/data if
    the DSR pin is off. If that's truely the case then can I get
    help/pointer to the exact source file so that I can change it to
    ignore DSR status and still log the data.

    Thanks.




    JDanSkinner@JDanSkinner.com (Dan Skinner) wrote in message news:<8ce22d01.0310211755.5aeb83f8@posting.google.com>...
    > Frank da Cruz wrote in message news:...
    > > In article , icurmt wrote:
    > > : I wasn't able to communicate successfully between two devices using
    > > : RS232. The show comm parameters are as under:
    > > :
    > > : /dev/ttyS0, speed:19200, mode:local, modem:none
    > > : flow:rts/cts, carrier-watchff
    > > :
    > > : CDff, DSRff, CTS:On, RIff, DTR: on, RTSn
    > > :
    > > : However, on another machine, where the communication worked, I had the
    > > : exact same comm parameters as above except that DSR was ON.
    > > :
    > > : I was wondering if through kermit can I control the DSR and set it to
    > > : 'On' so that communication works fine.
    > > :
    > > DSR is an *incoming* signal so Kermit can't control it. You'll need to
    > > rig up your cable to supply it; e.g. Wire local or remote DTR back to DSR.
    > >
    > > - Frank

    >
    > Tried and true null modem cable 25 pin D connectors
    > 1 ----- 1
    > 2 ----- 3 2 twisted pair cable 1 and 7 separate pairs
    > 3 ----- 2
    > 7 ----- 7
    >
    > 4 -| |- 4 4 & 5 jumpered in each head
    > 5 -| |- 5
    >
    > 6 -| |- 6 6 - 8 & 20 jumpered in each head
    > 8 -| |- 8
    > 20-| |-20
    >
    > Use xon xoff protocol.
    >
    > 9 pin connectors do literal translation but my memory won't recall
    > the pin numbers.
    >
    > Regards...Dan


  5. Re: DSR off ...

    In article <8ce22d01.0310211755.5aeb83f8@posting.google.com>,
    Dan Skinner wrote:
    : Tried and true null modem cable 25 pin D connectors
    : 1 ----- 1
    : 2 ----- 3 2 twisted pair cable 1 and 7 separate pairs
    : 3 ----- 2
    : 7 ----- 7
    :
    : 4 -| |- 4 4 & 5 jumpered in each head
    : 5 -| |- 5
    :
    : 6 -| |- 6 6 - 8 & 20 jumpered in each head
    : 8 -| |- 8
    : 20-| |-20
    :
    : Use xon xoff protocol.
    :
    That's one kind of null modem cable, called the "fakeout", in which each
    computer is reading back its own modem signals. When you actually want to
    detect whether the other computer is really there, and also be able to use
    hardware flow control, run A's DTR to B's CD and DSR (and v.v.), A's RTS to
    B's CTS (and v.v.)

    - Frank

  6. Re: DSR off ...

    In article , icurmt wrote:
    : Am I right to assume that kermit ignores any incoming messages/data if
    : the DSR pin is off.
    :
    It depends on the underlying operating system. Except in DOS, Kermit
    always works (and must work) through the OS's device drivers. Whatever
    they do, that's the rule.

    : If that's truely the case then can I get
    : help/pointer to the exact source file so that I can change it to
    : ignore DSR status and still log the data.
    :
    In Unix, sometimes you can open the same device with a different name to
    get a different device driver. For example in HP-UX /dev/cua0p0 is for
    use with modems, whereas /dev/ttyd0p0 is for direct cable connections.
    It depends on the specific OS and version (not on Kermit).

    - Frank

  7. Re: DSR off ...

    Thanks for your inputs.

    What looks like is that DTR pin is turned high during set line call
    and is turned low during hangup.

    If, I can keep the DTR pin low during the communication then it would
    solve my problem. Please let me know if there's a higher level call I
    can make through script to keep it on.

    Also read somewhere that setting speed to 0 and then turning it to
    non-zero would flip the DTR pin as well.

    Thanks.


    JDanSkinner@JDanSkinner.com (Dan Skinner) wrote in message news:<8ce22d01.0310211755.5aeb83f8@posting.google.com>...
    > Frank da Cruz wrote in message news:...
    > > In article , icurmt wrote:
    > > : I wasn't able to communicate successfully between two devices using
    > > : RS232. The show comm parameters are as under:
    > > :
    > > : /dev/ttyS0, speed:19200, mode:local, modem:none
    > > : flow:rts/cts, carrier-watchff
    > > :
    > > : CDff, DSRff, CTS:On, RIff, DTR: on, RTSn
    > > :
    > > : However, on another machine, where the communication worked, I had the
    > > : exact same comm parameters as above except that DSR was ON.
    > > :
    > > : I was wondering if through kermit can I control the DSR and set it to
    > > : 'On' so that communication works fine.
    > > :
    > > DSR is an *incoming* signal so Kermit can't control it. You'll need to
    > > rig up your cable to supply it; e.g. Wire local or remote DTR back to DSR.
    > >
    > > - Frank

    >
    > Tried and true null modem cable 25 pin D connectors
    > 1 ----- 1
    > 2 ----- 3 2 twisted pair cable 1 and 7 separate pairs
    > 3 ----- 2
    > 7 ----- 7
    >
    > 4 -| |- 4 4 & 5 jumpered in each head
    > 5 -| |- 5
    >
    > 6 -| |- 6 6 - 8 & 20 jumpered in each head
    > 8 -| |- 8
    > 20-| |-20
    >
    > Use xon xoff protocol.
    >
    > 9 pin connectors do literal translation but my memory won't recall
    > the pin numbers.
    >
    > Regards...Dan


  8. Re: DSR off ...

    In article , icurmt wrote:
    : Thanks for your inputs.
    :
    : What looks like is that DTR pin is turned high during set line call
    : and is turned low during hangup.
    :
    That's how it's supposed to work.

    : If, I can keep the DTR pin low during the communication then it would
    : solve my problem. Please let me know if there's a higher level call I
    : can make through script to keep it on.
    :
    Again, device drivers handle modem signals. In general, there is no API
    for turning on and off individual modem signals, but some OS's do have this.
    However, it is rarely necessary. The functions of modem signals are clearly
    defined in the standards and if you have the appropriate cables -- i.e.
    ones that connect the right output pin on one end to the right input pin on
    the other end, everything just works.

    : Also read somewhere that setting speed to 0 and then turning it to
    : non-zero would flip the DTR pin as well.
    :
    It depends on the operating system. Every OS has a different API for
    "hanging up" by turning DTR off, pausing, and then turning it on. Kermit
    does this for you without requiring you to know the details if you give
    a HANGUP command on a serial-port or modem connection.

    - Frank

  9. Re: DSR off ...

    Frank da Cruz wrote in message news:...
    > In article <8ce22d01.0310211755.5aeb83f8@posting.google.com>,
    > Dan Skinner wrote:
    > : Tried and true null modem cable 25 pin D connectors
    > : 1 ----- 1
    > : 2 ----- 3 2 twisted pair cable 1 and 7 separate pairs
    > : 3 ----- 2
    > : 7 ----- 7
    > :
    > : 4 -| |- 4 4 & 5 jumpered in each head
    > : 5 -| |- 5
    > :
    > : 6 -| |- 6 6 - 8 & 20 jumpered in each head
    > : 8 -| |- 8
    > : 20-| |-20
    > :
    > : Use xon xoff protocol.
    > :
    > That's one kind of null modem cable, called the "fakeout", in which each
    > computer is reading back its own modem signals. When you actually want to
    > detect whether the other computer is really there, and also be able to use
    > hardware flow control, run A's DTR to B's CD and DSR (and v.v.), A's RTS to
    > B's CTS (and v.v.)
    >
    > - Frank


    Agreed, and the more sophisticated lashings are important to more
    robust connections, but when I start fussing with control line values
    and all I want
    is to trade data between a couple of machines I've always got a
    "fakeout" cable
    and a couple of gender changers and 25 to 9 pin converters in my bag.
    If that doesn't work, it probably won't work . Well there is
    probably a breakout box buryied in the bottom of that bag someplace.
    Regards...Dan.

  10. Re: DSR off ...

    Thanks guys.

    Alright, let me give you more insight to why I am seeing all these
    problems. I am using the Single Board Computer to talk to the
    Microcontroller unit through serial ports. The DTR pin on the SBC is
    hacked to recycle the power on the MCU. Now when the communication is
    initiated, the DTR pin goes high(1) which resets the MCU and
    communication fails. Thats the reason that during "show comm"
    I see that DSR is off. Now when the communication terminates, the DTR
    is turned off (0) which turns the MCU on.

    Something which puzzles me is that why is DTR handshaking used here
    even when I am stating in kermit program to use the Xon/Xoff
    flowcontrol. I also tried the RTS/CTS handshaking but the result was
    same.

    Now if I use the Java program, which uses RXTX comm jar(communication
    program for Linux), then everything works fine. I see no issues. That
    makes me come to the conclusion that low-level api has nothing to do
    with it. It's gotta be somewhere in kermit where it is using DTR
    handshaking inspite of being asked to use RTS/CTS or Xon/Xoff.

    All $0.02 welcome.

    Thanks - Ray


    Frank da Cruz wrote in message news:...
    > In article , icurmt wrote:
    > : Thanks for your inputs.
    > :
    > : What looks like is that DTR pin is turned high during set line call
    > : and is turned low during hangup.
    > :
    > That's how it's supposed to work.
    >
    > : If, I can keep the DTR pin low during the communication then it would
    > : solve my problem. Please let me know if there's a higher level call I
    > : can make through script to keep it on.
    > :
    > Again, device drivers handle modem signals. In general, there is no API
    > for turning on and off individual modem signals, but some OS's do have this.
    > However, it is rarely necessary. The functions of modem signals are clearly
    > defined in the standards and if you have the appropriate cables -- i.e.
    > ones that connect the right output pin on one end to the right input pin on
    > the other end, everything just works.
    >
    > : Also read somewhere that setting speed to 0 and then turning it to
    > : non-zero would flip the DTR pin as well.
    > :
    > It depends on the operating system. Every OS has a different API for
    > "hanging up" by turning DTR off, pausing, and then turning it on. Kermit
    > does this for you without requiring you to know the details if you give
    > a HANGUP command on a serial-port or modem connection.
    >
    > - Frank


  11. Re: DSR off ...

    In article , icurmt wrote:
    : Alright, let me give you more insight to why I am seeing all these
    : problems. I am using the Single Board Computer to talk to the
    : Microcontroller unit through serial ports. The DTR pin on the SBC is
    : hacked to recycle the power on the MCU. Now when the communication is
    : initiated, the DTR pin goes high(1) which resets the MCU and
    : communication fails. Thats the reason that during "show comm"
    : I see that DSR is off. Now when the communication terminates, the DTR
    : is turned off (0) which turns the MCU on.
    :
    : Something which puzzles me is that why is DTR handshaking used here
    : even when I am stating in kermit program to use the Xon/Xoff
    : flowcontrol. I also tried the RTS/CTS handshaking but the result was
    : same.
    :
    DTR and flow control (usually) have nothing to do with each other.
    DTR is a signal from the computer to the modem saying "I am turned on"
    and/or "this serial port is open". By definition, when you turn it off,
    this supposed to break the connection.

    Unfortunately in this case, Kermit is not a general-purpose modem-control
    manipulating program. It operates at a higher level. "set line /dev/xxx"
    turns DTR on (and in most cases also RTS). Closing the device turns it off.
    RTS/CTS are used by the device driver (transparently to Kermit) for flow
    control if you have "set flow rts/cts".

    CD, CTS, DSR, and RI are incoming signals -- "read only". You can see
    them with "show comm" and you can test them with the WAIT command.

    The only way in Kermit that you can touch DTR is with the HANGUP command,
    which sets DTR low for about 250 milliseconds, then brings it back, which
    is how one tells a modem to hang up a telephone connection.

    - Frank

  12. Re: DSR off ...

    Thanks Frank.

    I figured it out. I took the port's file descriptor, ttyfd from the
    kermit script passed it to my C program to toggle the DTR state.

    Everything works fine now. Thanks for your timely inputs.

    Ray

    Frank da Cruz wrote in message news:...
    > In article , icurmt wrote:
    > : Alright, let me give you more insight to why I am seeing all these
    > : problems. I am using the Single Board Computer to talk to the
    > : Microcontroller unit through serial ports. The DTR pin on the SBC is
    > : hacked to recycle the power on the MCU. Now when the communication is
    > : initiated, the DTR pin goes high(1) which resets the MCU and
    > : communication fails. Thats the reason that during "show comm"
    > : I see that DSR is off. Now when the communication terminates, the DTR
    > : is turned off (0) which turns the MCU on.
    > :
    > : Something which puzzles me is that why is DTR handshaking used here
    > : even when I am stating in kermit program to use the Xon/Xoff
    > : flowcontrol. I also tried the RTS/CTS handshaking but the result was
    > : same.
    > :
    > DTR and flow control (usually) have nothing to do with each other.
    > DTR is a signal from the computer to the modem saying "I am turned on"
    > and/or "this serial port is open". By definition, when you turn it off,
    > this supposed to break the connection.
    >
    > Unfortunately in this case, Kermit is not a general-purpose modem-control
    > manipulating program. It operates at a higher level. "set line /dev/xxx"
    > turns DTR on (and in most cases also RTS). Closing the device turns it off.
    > RTS/CTS are used by the device driver (transparently to Kermit) for flow
    > control if you have "set flow rts/cts".
    >
    > CD, CTS, DSR, and RI are incoming signals -- "read only". You can see
    > them with "show comm" and you can test them with the WAIT command.
    >
    > The only way in Kermit that you can touch DTR is with the HANGUP command,
    > which sets DTR low for about 250 milliseconds, then brings it back, which
    > is how one tells a modem to hang up a telephone connection.
    >
    > - Frank


+ Reply to Thread